> > Hi, > > On Wed, Sep 2, 2026 at 10:30 AM Zqiang <[email protected]> wrote: > > > > > > > > > Hi, > > > > > > On Tue, Sep 1, 2026 at 5:19 AM Zqiang <[email protected]> wrote: > > > > > > > > > The dlm_lowcomms_exit() and dlm_midcomms_exit() iterate over the > > > srcu protected connection and node hash tables and hand each > > > element to call_srcu() for deferred freeing (connection_release() > > > and midcomms_node_release()). call_srcu() is asynchronous: the > > > callbacks are invoked only after an SRCU grace period, which may > > > happen after the exit function has already returned. > > > > > > These exit functions are reached from exit_dlm() on module unload. > > > Once they return, module teardown continues and the module text > > > may be unloaded while call_srcu() callbacks are still pending. When > > > such a callback finally runs, it executes freed module code and > > > touches the static SRCU domains that are being torn down, resulting > > > in a use-after-free. > > > > I should rephrase it: > > > > Due to missed call to the srcu_barrier(), when invoke cleanup_srcu_struct() > > > Then there need to be a MUST call of srcu_barrier() before > cleanup_srcu_struct() every time.
If there are some call_srcu() call, the srcu_barrier() should be called before cleanup_srcu_struct(). usually, when the cleanup_srcu_struct() run, we should ensure that there are no pending SRCU callbacks or ongoing SRCU grace periods at this time. there are another reason: The midcomms_node_release() srcu callback can call call_rcu(), we must wait the all call_rcu() to complete, because rcu_barrier() which in dlm_memory_exit() is required to successfully intercept these RCU callbacks. Thanks Zqiang > > I am confused here. > > - Alex >
