On Mon, Feb 24, 2025 at 11:06:01AM -0800, Paul E. McKenney wrote: > On Mon, Feb 24, 2025 at 02:36:59PM +0100, Uladzislau Rezki (Sony) wrote: > > Switch for using of get_state_synchronize_rcu_full() and > > poll_state_synchronize_rcu_full() pair for debug a normal > > synchronize_rcu() call. > > > > Just using "not" full APIs to identify if a grace period > > is passed or not might lead to a false kernel splat. > > > > Link: https://lore.kernel.org/lkml/Z5ikQeVmVdsWQrdD@pc636/T/ > > Fixes: 988f569ae041 ("rcu: Reduce synchronize_rcu() latency") > > Reported-by: cheung wall <zzqq0103.hey@xxxxxxxxx> > > Signed-off-by: Uladzislau Rezki (Sony) <urezki@xxxxxxxxx> > > --- > > include/linux/rcupdate_wait.h | 4 ++++ > > kernel/rcu/tree.c | 8 +++----- > > 2 files changed, 7 insertions(+), 5 deletions(-) > > > > diff --git a/include/linux/rcupdate_wait.h b/include/linux/rcupdate_wait.h > > index f9bed3d3f78d..a16fc2a9a7d7 100644 > > --- a/include/linux/rcupdate_wait.h > > +++ b/include/linux/rcupdate_wait.h > > @@ -16,6 +16,10 @@ > > struct rcu_synchronize { > > struct rcu_head head; > > struct completion completion; > > +#ifdef CONFIG_PROVE_RCU > > + /* This is for testing. */ > > + struct rcu_gp_oldstate oldstate; > > +#endif > > This causes the build to fail on TREE01. One way to make the build > succeed is to remove the #ifdefs above. Another way would be to add > #ifdefs to the WARN_ONCE() below. I suspect that removing the #ifdefs > is best, at least until such time as people start passing many tens > of SRCU instances to synchronize_rcu_mult() or some such (which seems > quite unlikely). > > Thoughts? > Right, i agree. I will repost this series. Thank you for checking and testing :) -- Uladzislau Rezki
