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

[Paul E. McKenney]

On Thu, Aug 20, 2026 at 03:43:01PM +0100, David Woodhouse wrote:
> On Tue, 2026-08-18 at 11:18 -0700, Paul E. McKenney wrote:
> > On Thu, Aug 13, 2026 at 08:54:44AM +0100, David Woodhouse wrote:
> > > On Wed, 2026-08-12 at 14:38 -0700, Paul E. McKenney wrote:
> > > > If not, please let me know, and I will put together that does the
> > > > job.
> > > 
> > > If you're working on that, I assume it'd need the readers to be known-
> > > atomic. So if any of the read-side SRCU_READ_FLAVOR_ATOMIC thing I
> > > already threw together is useful, you can find it in my tree at
> > > https://git.infradead.org/?p=users/dwmw2/linux.git;a=shortlog;h=refs/heads/srcu-atomic
> > 
> > Thank you, happy to steal pieces of that with attribution.  ;-)
> > 
> > My current plan says that if you have an atomic SRCU on which you
> > use srcu_read_lock_atomic() and srcu_read_unlock_atomic(), you only
> > ever get to use synchronize_srcu_atomic(), never synchronize_srcu(),
> > synchronize_srcu_expedited(), or call_srcu().  Does that work for you?
> 
> I just said this elsewhere in the thread¹ but I don't necessarily
> expect you to be following that. So to bring it back here...
> 
> My mental model for srcu_read_lock_atomic() was that it was always
> atomic, even on RT — it was basically equivalent to a raw spinlock.
> 
> In fact I think it would be OK for it to be equivalent to a *plain*
> spinlock — i.e. atomic on non-RT, but might sleep on RT.
> 
> When I wrote that previous email I was thinking that might end up being
> additional complexity in your implementation, but as I type this I
> guess it could be as simple as falling back to the normal non-atomic
> case for RT?
> 
> ¹ https://lore.kernel.org/all/448c5c0128b08ab98d175ae1099ff4d4874e49b3.camel@xxxxxxxxxxxxx/

The current state is that if you invoke synchronize_srcu_atomic()
from a given context, then srcu_read_lock_atomic() must be invoked
from that same context, or a more strict one.

So, for example, you can disable preemption across your invocation of
synchronize_srcu_atomic(), but only if you also do so across the entire
reader, starting before srcu_read_lock_atomic() and ending after the
matching srcu_read_unlock_atomic().  Or you could instead disable
interrupts across the entire SRCU reader.

Does that work?

Also, Tiny SRCU atomic turned out to be a bit more complicated than
we were thinking due to lazy preemption.  ;-)

If you want a sneak preview, please feel free to take a look at
the first few commits on the "dev" branch of my -rcu tree.

							Thanx, Paul