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

[David Woodhouse]

On Wed, 2026-08-12 at 10:49 -0300, Jason Gunthorpe wrote:
> On Wed, Aug 12, 2026 at 02:46:08PM +0100, David Woodhouse wrote:
> > 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).
> 
> These all seem like good ideas, then you don't need to touch the
> notifiers..

I'll rephrase that for my own understanding:

*If* we go all the way to building a whole SRCU flavour for this *and*
implementing a spin-only variant of srcu_synchronize() which is
tailored to the atomic-reader use case, *then* we don't need to remove
the non_block_{start,end} guards around the MMU notifiers, which are
basically never being called anyway and don't actually seem to protect
against any real bugs.

Yes?

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