On Sun, Jun 09, 2024 at 11:37:45AM -0400, Kent Overstreet wrote: > On Sat, Jun 08, 2024 at 08:25:53PM -0700, Paul E. McKenney wrote: > > Could you please try something like this just before the call to > > cleanup_srcu_struct()? > > > > WARN_ON_ONCE(poll_state_synchronize_srcu(&c->btree_trans_barrier, ck->btree_trans_barrier_seq); > > Which seq was this supposed to be? All keys have been freed by this > point... Or, alternatively, where in the code is this supposed to be? If there is no convenient point in the code to grab the most recent return value from start_poll_synchronize_srcu(), another thing to do is to invoke either synchronize_srcu() or synchronize_srcu_expedited() just before the call to cleanup_srcu_struct(). Another approach is to use get_state_synchronize_srcu() instead of start_poll_synchronize_srcu(), and have a self-reposting SRCU callback to keep the grace periods going. Then you would set a flag that stopped it from self-posting, then do srcu_barrier(). With careful memory ordering. There are quite a few techniques to shut down the self-reposting SRCU callback when there is nothing for it to do and to restart it if need be. But just doing a synchronize_srcu() or synchronize_srcu_expedited() is a lot simpler and probably does the job. Thanx, Paul
