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

[David Woodhouse]

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.

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

> Alternatively, there's always the poor-man RCU using an rwlock_t; you
> do read_lock/read_unlock as usual for begin/end of reads, while the
> write side does
> 
>    write_lock(&kvm->gpc_readers);
>    write_unlock(&kvm->gpc_readers);
> 
> in place of synchronize_src().

And now we've come full circle to the rwlock we already *have* — but
which is back to a shared cache line for readers, and which RT turns
into a sleeping lock, which is what I started out trying to fix in the
first place.

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.

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