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

[David Woodhouse]

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?

> >   * 2a55908bb12d srcu: Keep a spare node array so srcu_gp_end() need not block in reclaim
> 
> This should not be necessary given that call_srcu(), synchronize_srcu(),
> synchronize_srcu_expedited(), and start_poll_synchronize_srcu() are all
> ruled out for atomic srcu_struct structures.  Thus, there will never be
> a conversion to big, and thus no memory allocation.
> 
> Or am I missing something here?

Agreed. I just didn't get round to dropping it yet. I'll do so.

Thanks again.

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