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

[Sean Christopherson]

On Tue, Sep 01, 2026, David Woodhouse wrote:
> On Mon, 2026-08-31 at 17:58 -0700, Paul E. McKenney wrote:
> > On Fri, Aug 28, 2026 at 12:25:01AM +0100, David Woodhouse wrote:
> > 
> > 
> > >   * 23f10e07aba3 srcu: Add try_synchronize_srcu() for callers which can prove readers absent
> > 
> > I do not intend to provide a separate API for this given the possibility
> > of indefinite postponement.
> 
> Makes sense. In that case, calling it internally from the 'right'
> places becomes important, as the callers who care can't do so for
> themselves.
> 
> We discussed the fact that synchronize_srcu_expedited() will also want
> to use the same fast path.
> 
> I'm also looking back to Sean's call_srcu_expedited() patch from March:
> https://lore.kernel.org/all/20260309193059.2244645-1-seanjc@xxxxxxxxxx/
> 
> 
> | Due to differences in how VMMs manage guest devices, and in the
> | architecture being emulated by userspace, some updates trigger call_srcu()
> | with concurrent readers (i.e. while the VM is active), while others occur
> | without readers, e.g. when configuring devices during a pre-boot setup.
> | For the later case (no concurrent readers), using the vanilla call_srcu()
> | is problematic, as it can kick off a normal grace period (totally fine for
> | freeing the object) and effectively transfer the non-expedited grace period
> | to the upcoming synchronize_srcu_expedited().
> 
> So the offending path uses call_srcu() and triggers a normal GP, while
> the victim calls synchronize_srcu_expedited() and gets stuck behind
> that non-expedited GP.
> 
> Sean, if the victim is the "no concurrent readers" code path, as you
> said above, do you think the fast path in the victim should suffice,
> without the cost of an expedited GP for every bus registration?

IIUC, you're asking if being able to use try_synchronize_srcu() for the fast/happy
of synchronize_srcu_expedited() (i.e. for kvm_swap_active_memslots()()), even if
there's an in-flight GP, would suffice for a fix of the regression introduced by
commit 7d9a0273c459 ("KVM: Avoid synchronize_srcu() in kvm_io_bus_register_dev()").

If my understanding is correct, then yes, that should work, and presumably would
be a notable improvement overall.