Re: [PATCH 03/13] srcutree: Add reader-free fastpath to synchronize_srcu_atomic()

[Paul E. McKenney]

On Tue, Sep 08, 2026 at 11:09:34PM +0100, David Woodhouse wrote:
> On Tue, 2026-09-08 at 14:54 -0700, Paul E. McKenney wrote:
> > 
> > And another option is to pull the fastpath up earlier, before
> > checking and/or acquiring ->srcu_atomic_gp_flag.  But this is a
> > bit more complicated from a concurrency viewpoint, at least if
> > we are to interact normally with get_state_synchronize_srcu() and
> > poll_state_synchronize_srcu().  For example:
> > 
> > 	srcu_state = get_state_synchronize_srcu(ssp);
> > 	synchronize_srcu_atomic(ssp);
> > 	WARN_ON_ONCE(!poll_state_synchronize_srcu(ssp, srcu_state));
> > 
> > Without at least some mucking with the grace-period mechanism, that
> > WARN_ON_ONCE() could trigger, which just might not be universally
> > considered to be a friendly act.  ;-)
> > 
> > So it would be very good to keep the fastpath where Kunwu put it, if
> > that works reasonably.
> 
> Could we not just declare that synchronize_srcu_atomic() *isn't*
> guaranteed to drive a GP, so the above code isn't valid? Why poll for a
> thing that's atomic? Is that a likely use case?

We *could*, but one more thing to explain and one more thing for users
to get wrong.

> And you've already forbidden start_poll_synchronize_srcu() for atomic,
> haven't you?

Yes, because there is no such thing as an asynchronous atomic SRCU
grace period.

> I concede that the same logic doesn't work quite as well for
> synchronize_srcu_expedited(), as it's an established API. Could we
> retcon that one?

My hope is that this same sort of approach works there as well.

Hey, I can dream, can't I?  ;-)

							Thanx, Paul