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

[David Woodhouse]

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?

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

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?

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