Re: [PATCH] mm/mmu_notifier: Remove non_block_start/end() from notifier invocation

On 2026-08-12 18:49:50 [+0100], David Woodhouse wrote:
> >Making synchronize_srcu_atomic() spin in CONFIG_PREEMPT_RT is a
> >slightly tall request - it's basically putting it on the same level as
> >raw_spinlock. But if the MMU notifier guys really want to make OOM
> >notifiers atomic, this would be basically the only way to do so.
> >
> >If instead it's okay to remove nonblock_start/end under
> >CONFIG_PREEMPT_RT, for RT kernels I'd rather avoid
> >preempt_disable/enable and only make synchronize_srcu_atomic() try to
> >skip the index flip:
> >
> >   if (!try_synchronize_srcu(ssp))
> >      synchronize_srcu_expedited(ssp);
> 
> Yeah, so in the normal case it's truly atomic but in the RT case both
> readers and grace periods quietly start to sleep again... just like
> spinlocks in RT. That seems reasonable.

I just caught up with the thread.
The task_struct::non_block_count is not properly defined IMHO. It talks
about sleeping and atomic but it is fine to acquire a spinlock_t which
is a spinning lock on !RT.
The other user of non_block_start() is pwm_set_waveform_might_sleep()
where it is used if the pwmchip's lock is a spinlock_t and not a
mutex_t. Again, it seems fine to acquire a spinlock_t.

So it seems if a lock is acquired which is spinning on !RT and part that
these locks are turned into sleeping locks shouldn't lead to a problem.

The splat referenced in
	https://lore.kernel.org/all/[email protected]/

complains only about non_block, the other fields are zero.
In that case it is just a question of how might_sleep() is implemented
and we could skip the warning for the few locks that sleep on RT and
spin on !RT. (FTR: There is also no RCU warning on RT if we sleep
(schedule()) within a RCU read section while blocking on a spinlock_t
but there is a warning if we block on a mutex_t).

In
   https://lore.kernel.org/all/[email protected]
there was a suggestion for "srcu: Add an ATOMIC reader flavor and a spinning
synchronize_srcu_atomic()". This one had preempt_disable() in
srcu_read_lock_atomic(). This is bad as not only forbids to acquire any
sleeping locks (such as spinlock_t) but it also does not allow any
scheduling of any kind within this section.

So if it is *just* the annoying splat on RT, I could try to teach
might_sleep() no to be upset here.

Sebastian