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

[David Woodhouse]

On Wed, 2026-08-12 at 09:27 -0300, Jason Gunthorpe wrote:
> On Wed, Aug 12, 2026 at 09:21:31AM +0100, David Woodhouse wrote:
> > On Wed, 2026-08-12 at 10:14 +0200, Michal Hocko wrote:
> > > On Tue 11-08-26 16:24:48, David Woodhouse wrote:
> > > [...]
> > > > I had a second reason for disabling the overzealous check too: to allow
> > > > SRCU grace periods within the notifier callbacks.
> > > 
> > > Is there a way that srcu barrier could cause an indirect dependency on
> > > memory allocation? In other words what might block the scru to complete?
> > 
> > Not after https://lore.kernel.org/all/6eed3fe3461e9690b486ca98fa7563f60d3940ff.camel@xxxxxxxxxxxxx/
> 
> The user of the SRCU might have a read side that wraps an allocate. In
> general it is not safe.

Sure, the *general* case of Sleepable RCU can do all kinds of stuff in
the read-side sections.

But in *this* case they were all read_lock_irqsave() thus far, and they
absolutely categorically do not.

> I'm skeptical that without special API and documentation the KVM
> special use of SRCU you've outlined will not remain working long term
> too..

I hear you. I'm less sceptical, given the use case, but I'll certainly
concede that the universe is known for inventing better idiots.

I'm certainly not averse to having a wrapper so that the read sections
don't just srcu_read_lock() directly, but also get a sanity check
(non_block_start? local_irq_save? what would it actually be? does it
have to be different for the hardirq vs. process-context invocations?)
for free.

Or instead of a GPC-specific wrapper, do we make it a first-class SRCU
citizen, SRCU_READ_FLAVOR_ATOMIC? If it disables preemption, we'd know
that lock+unlock must happen on the *same* CPU, which could potentially
simplify my new try_synchronize_srcu() and/or allow for a *spinning*
grace period if we really do want that (although I'm unconvinced; it's
*latency* we care about here, and punting to the WQ when we *already*
have to wait is fair enough).

Either way, I see that as a mostly cosmetic follow-on from the real
fixes I'm chasing here.

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