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

[Sean Christopherson <seanjc@google.com>]

On Tue, Aug 11, 2026, David Woodhouse wrote:
> On Tue, 2026-08-11 at 22:21 +0200, Paolo Bonzini wrote:
> > 
> > for_each_present_cpu(cpu)
> >     if (per_cpu(kvm_gpc_reader, cpu) == gpc)
> >         cpumask_set_cpu(cpu, gpc_readers);
> > __kvm_kick_many_cpus(cpus, wait);
> 
> 
> I'm literally sitting here watching you reinvent what SRCU already does.

The problem, for me at least, is that SRCU does this and a _lot_ more.

> Which, again, is *fine* given the behaviour of *these* read-side sections.

Well, yeah.  Why use a nailgun to put a nail into the wall to hang a picture
frame? (other than the indisputable fact that power tools are fun).  SRCU is
fantastic infrastructure, but I genuinely think it's not the right fit here,
especially since we'll likely need a different solution for in-guest readers
anyways.

> I get it. RCU is a versatile tool, and in *some* cases the *Sleepable*
> variant of RCU gets used in ways which would cause grace period latencies
> which are thoroughly unacceptable in an MMU notifier callback.
> 
> But in the specific case of a dedicated kvm->gpc_srcu whose only
> readers are tiny snippets of code that until today were always run with
> rwlock_irqsave? That is *not* Jason's worst-case bugbear. It's fine.

I agree it's more than likely fine for your use case, I'm not convinced it'll be
fine for use cases that heavily overcommit memory, or do NUMA balancing, or (close
your eyes) enable KSM.

E.g. it doesn't take all that much for even a single expedited sync to generate
a delay of 20ms.
https://lore.kernel.org/all/20260309193059.2244645-1-seanjc@google.com