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?
smime.p7s
Description: S/MIME cryptographic signature
