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

On Tue, 2026-08-11 at 13:06 -0700, Sean Christopherson wrote:
> 
> +static inline unsigned long kvm_gpc_read_begin(struct kvm *kvm)
> +{
> +	unsigned long flags;
> +
> +	local_irq_save(flags);
> +	cpumask_set_cpu(smp_processor_id(), kvm->gpc_readers);
> +}
> +
> +static inline void kvm_gpc_read_end(struct kvm *kvm, unsigned long flags)
> +{
> +	cpumask_clear_cpu(smp_processor_id(), kvm->gpc_readers);
> +	local_irq_restore(flags);
> +}
> +

Nah, those are all on the same cache line. SRCU doesn't do that, does it?
You end up basically reinventing SRCU.

I'm OK with having a special helper for kvm_gpc_read_begin/end. I was
actually tempted to do that as patch 1 in the series which converted to
RCU — it's then an implementation detail whether it's rwlock, spinlock,
rwlock-except-on-RT-which-gets-raw-spinlock, SRCU or whatever.

If we use the helper and still make it use SRCU, we can still impose
some of the invariants which make it actually *OK* to use SRCU because
we know we'll never hit those worst-case latencies that Jason is
worried about — like adding non_block_start()/non_block_end() in the
helpers to ensure that we keep the atomic semantics within the locks,
that rwlocks always previously enforced, etc.

It isn't *strictly* non_block_start/end because because we invoke it in
hardirq context, of course. We'd have to work that detail out. Maybe it
*is* local_irq_save(); not because it's strictly necessary to do so but
just because it comes with the desired sanity-checks.

But either way, the point is that whether you reinvent SRCU or not, it
all works purely because we know about the behaviour of the read-side
users.