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

[Sean Christopherson]

On Tue, Sep 01, 2026, Paul E. McKenney wrote:
> On Tue, Sep 01, 2026 at 12:12:51PM -0700, Sean Christopherson wrote:
> > 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.
> 
> Then we could abandon synchronize_rcu_atomic()?  That would not be a
> bad thing from my perspective.
> 
> Just to be sure, please note that synchronize_rcu_expedited() can and
> sometimes does sleep in order to avoid odd corner cases that could
> otherwise pointlessly monopolize a CPU.

I think one (or both) of us is confused.  I thought David was asking if we could
avoiding adding call_srcu_expedited(), because the proposed try_synchronize_srcu()
would fix a regression related to KVM's use of synchronize_srcu_expedited().

I don't think that has anything to do with non-sleepable RCU?  Or is there a
separate discussion and/or implicitations I don't understand?