Re: [PATCH] mm/mmu_notifier: Remove non_block_start/end() from notifier invocation
From: Paul E. McKenney
Date: Wed Aug 26 2026 - 12:28:39 EST
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.
> For that to work, we will need a wrapper sort of like what we have for
> synchronize_rcu_tasks_trace(), but one that does SRCU for !PREEMPT_RT
> and vanilla RCU for PREEMPT_RT.
>
> Sebastian, thoughts?
Everyone, thoughts? ;-)
Thanx, Paul