On 2025-04-02 16:23:50 [+0200], Oleg Nesterov wrote:
> OK, it seems we can't understand each other. Probably my fault.
>
> So, it think that
>
> static inline bool __seqprop_preemptible(const seqcount_t *s)
> {
> return false;
> }
>
> should return true. Well because it is preemptible just like
> SEQCOUNT_LOCKNAME(mutex) or, if PREEMPT_RT=y, SEQCOUNT_LOCKNAME(spinlock).
>
> Am I wrong?
A seqcount_t has no lock associated with so it is not preemptible. It
always refers to the lock. This should come from extern so it not only
disables preemption but also ensures that there can only be one writer.
The "disabling preemption" is only there to ensure progress is made in
reasonable time: You should not get preempted in your write section. If
the writer gets preempted then nothing bad (as in *boom*) will happen
because you ensured that you have only one writer can enter the section.
In that scenario the reader will spin on the counter until the writer
gets back on the CPU and completes the write section and while doing so
wasting resources. No boom, just wasting resources.
If you make __seqprop_preemptible() return true then
write_seqcount_begin() for seqcount_t will disable preemption on its
own. You could now remove all preempt_disable() around its callers. So
far so good as everyone should have one.
The problem here is that for !RT only seqcount_mutex_t gets preemption
disabled. For RT none of the seqcount_t variants get preemption disabled
but rely on lock+unlock mechanism to ensure that progress is made.
With this change it would also disable preemption for RT and I don't
know if it is is always the smart thing to do. Usually if the splats
pop up the users can be pointed to something else. Then we have also the
"limited" API where you can't use spinlock_t within the seqcount because
it would break PREEMPT_RT.
I've been now verbose to make up for the other few times where I was
brief :)
> Oleg.
Sebastian
