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

[Paul E. McKenney]

On Wed, Aug 26, 2026 at 09:30:43PM +0100, David Woodhouse wrote:
> On 26 August 2026 20:59:31 BST, "Paul E. McKenney" <paulmck@xxxxxxxxxx> wrote:
> >On Wed, Aug 26, 2026 at 07:01:24PM +0100, David Woodhouse wrote:
> >> On 26 August 2026 17:28:27 BST, "Paul E. McKenney" <paulmck@xxxxxxxxxx> wrote:
> >> >On Wed, Aug 26, 2026 at 08:05:06AM -0700, Paul E. McKenney wrote:
> >> >> On Wed, Aug 26, 2026 at 08:38:27AM +0100, David Woodhouse wrote:
> >> >> > On Wed, 2026-08-26 at 09:32 +0200, Sebastian Andrzej Siewior wrote:
> >> >> > > On 2026-08-25 13:51:14 [-0700], Paul E. McKenney wrote:
> >> >> > > > Very good, preemption disabling it is!  It is quite possible that the
> >> >> > > > PREEMPT_RT guys will need something else, but one thing at a time.
> >> >> > > 
> >> >> > > This reminds me of classic RCU ;) It might work in this use case but I
> >> >> > > am afraid that other users might come along where it actually hurts.
> >> >> > > With PREEMPT LAZY the preemption within the read-section should
> >> >> > > hopefully be the exception.
> >> >> > 
> >> >> > Given the way that PREEMPT_RT treats other locks like spinlocks and
> >> >> > rwlocks — turning them into sleeping locks — I suspect it makes most
> >> >> > sense, and is consistent, to also turn rcu_read_lock_atomic() and
> >> >> > synchronize_rcu_atomic() into plain rcu_read_lock() and
> >> >> > try_synchronize_srcu()+synchronize_scru_expedited().
> >> >> 
> >> >> That makes a lot of sense to me.
> >> >
> >> >Another option is to instead fall back to non-atomic SRCU.
> >> 
> >> That's exactly what I thought I was suggesting; I think I left an 's' out though :)
> >
> >Heh!!!
> >
> >About 20 years ago, I was shocked to learn of a valid use case involving
> >sleeping RCU readers, which resulted in SRCU.  And now it is time
> >to be shocked at non-sleeping sleeping RCU readers, and especially a
> >non-sleeping grace-period wait.  ;-)
> >
> >Anyway, easy enough:
> >
> >#ifdef CONFIG_PREEMPT_RT
> >DEFINE_SRCU(whatever);
> >#define my_srcu_read_lock() srcu_read_lock(&whatever);
> >#define my_srcu_read_unlock(idx) srcu_read_unlock(&whatever, (idx));
> >#define my_synchronize_srcu() synchronize_srcu(&whatever);
> >#else
> >DEFINE_SRCU_ATOMIC(whatever);
> >#define my_srcu_read_lock() srcu_read_lock_atomic(&whatever);
> >#define my_srcu_read_unlock(idx) srcu_read_unlock_atomic(&whatever, (idx));
> >#define my_synchronize_srcu() synchronize_srcu_atomic(&whatever);
> >#endif
> 
> We could do that for the KVM GPC locking, but more consistent would be to change *all* users of the 'atomic' lock under PREEMPT_RT to silently get the sleeping version instead, like PREEMPT_RT does with spinlocks and rwlocks.
> 
> So it's srcu_read_lock_atomic() itself (et al) which would get that if/else treatment.

OK, the traditional approach is that raw_synchronize_srcu_atomic() and
friends with the raw_ prefix are always atomic, and without the raw_
prefix it is atomic for !PREEMPT_RT and non-atomic otherwise.  You would
use the non-_raw primitives.

Easy enough to do.  But does it do the job, both from a PREEMPT_RT
perspective and a notifier perspective?

And notifiers (though a different type of them) were the first use case
for SRCU.  ;-)

							Thanx, Paul