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

[David Woodhouse]

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/

Attachment: smime.p7s
Description: S/MIME cryptographic signature