Re: [PATCH v2 04/21] srcutree: Add an atomic Tree SRCU

[Paul E. McKenney]

On Thu, Oct 08, 2026 at 09:39:29AM +0200, David Woodhouse wrote:
> On Wed, 2026-10-07 at 13:59 -0700, Paul E. McKenney wrote:
> > Some dedicated srcu_struct users have read-side critical sections
> > which are short, never sleep, and never block on anything which may
> > itself depend on memory allocation — because they were, until
> > recently, spinlock or rwlock critical sections. For such a domain the
> > update side can safely wait for readers by spinning, from contexts
> > where sleeping is undesirable or the grace-period machinery's
> > latency (workqueue scheduling, jiffy-paced retries) dominates the
> > actual reader drain time.
> > 
> > But that is only safe if every reader keeps the promise. Make the
> > promise explicit and machine-checkable:
> > 
> >  - srcu_read_lock_atomic() / srcu_read_unlock_atomic() enter the
> >    usual (smp_mb-based) read-side critical section with preemption
> >    disabled and (except in hardirq, where it is redundant)
> >    non_block_start() armed, recording SRCU_READ_FLAVOR_ATOMIC in the
> >    per-CPU reader flavor. Disabling preemption enforces the
> >    no-sleeping promise on every configuration and bounds the section,
> >    so it is always running on some CPU; non_block_start() extends the
> >    enforcement to even potentially-sleeping calls on paths which
> >    happen not to block. The existing reader-flavor consistency checks
> >    complain about any mixing with other flavors.
> > 
> >  - synchronize_srcu_atomic() waits for all pre-existing readers by
> >    repeating the try_synchronize_srcu() both-epoch counter proof with
> >    cpu_relax() until it succeeds: no sleeping, no index flip, no
> >    grace-period sequence update, and therefore no interaction with
> >    concurrent call_srcu(), synchronize_srcu() or srcu_barrier(). It
> >    always provides the full grace-period guarantee: if the domain
> >    turns out to have had readers of any other flavor — a caller bug,
> >    since such a reader may be asleep and spinning on it would be
> >    unbounded — it complains and falls back to a real (sleeping) grace
> >    period internally, that being the only correct wait for a
> >    possibly-sleeping reader. The flavor mask is rechecked on every
> >    iteration so a first non-atomic reader appearing mid-spin takes
> >    the same path.
> > 
> > The immediate motivation is the proposed conversion of KVM's
> > gfn_to_pfn_cache to SRCU¹, whose mmu_notifier invalidation path drains
> > readers before the primary MMU zaps a page. With the readers declared
> > atomic, that drain becomes spin-only: no sleeping at all in the
> > notifier, bounded by the longest reader section, satisfying even the
> > strictest reading of the OOM-reaper non-blocking requirement without
> > needing to touch the non_block_start() annotation².
> > 
> > This commit also adds atomic-SRCU-specific initializers:
> > init_srcu_struct_atomic(), DEFINE_SRCU_ATOMIC(), and
> > DEFINE_STATIC_SRCU_ATOMIC().
> > 
> > This commit implements only Tree SRCU.  Tiny SRCU will follow.
> > 
> > ¹ https://lore.kernel.org/all/20260811132237.102400-1-dwmw2@xxxxxxxxxxxxx/
> > ² https://lore.kernel.org/all/20260812134934.GC662699@xxxxxxxx/
> > 
> > [ paulmck: Apply Kunwu Chan feedback. ]
> > 
> > Co-developed-by: David Woodhouse <dwmw2@xxxxxxxxxxxxx>
> > Signed-off-by: David Woodhouse <dwmw2@xxxxxxxxxxxxx>
> > Assisted-by: Claude:claude-mythos-5
> > Signed-off-by: Paul E. McKenney <paulmck@xxxxxxxxxx>
> 
> Thank you for seeing this concept through to completion.
> 
> If it isn't already too late (i.e. if it hasn't already made it to a
> tree where changing commit-ids is painful), please could you change my
> attribution to use the dwmw@xxxxxxxxxxxx email address for both Co-
> developed-by: and Signed-off-by: tags? I'm fairly sure you made up that
> Signed-off-by: with the infradead address, which is naughty of you :)

Indeed, I would have grabbed the first email I could find from you and
applied the From: field from that email, as opposed to finding the exact
email containing your prototype of the patch and then locating and copying
out the Signed-off-by.  And if I were to happen to find the email that
I am now replying to, I would once again get infradead rather than amazon.

Apologies, but life was flowing fast, and it probably will be from time
to time in the future.  So thank you for checking and please continue
to do so.

> I tell people you should only ever cut-and-paste SoB lines, because
> that way the magic is intact. So here are the two you need for patches
> 4 and 5 of this series:
> 
> Signed-off-by: David Woodhouse <dwmw@xxxxxxxxxxxx>
> Signed-off-by: David Woodhouse <dwmw@xxxxxxxxxxxx>

Thank you again, and I have this note to myself for my next rebase:

a5130cf7b27f ("srcutree: Add an atomic Tree SRCU")
85d5f89bdc42 ("srcutiny: Add an atomic Tiny SRCU")
	Co-developed-by: David Woodhouse <dwmw@xxxxxxxxxxxx>
	Signed-off-by: David Woodhouse <dwmw@xxxxxxxxxxxx>

Does that cover it?

And while we are discussing, how goes the use case?

							Thanx, Paul