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

[David Woodhouse]

On Tue, 2026-09-01 at 15:51 -0700, Sean Christopherson wrote:
> 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().

Indeed. This is a *separate* problem, for which you had previously
proposed adding call_srcu_expedited(), but it looks like having
try_synchronize_scru() as a fast path of synchronize_srcu_expedited()
would suffice.

We do still need synchronize_srcu_atomic() for the MM notifier case for
which we originally built it.

> 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?

I think the lack of 's' there was just a typo. This is synchronize_srcu_atomic().

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