From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mta0.migadu.com (out-218.mta0.migadu.com [91.218.175.218]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 92A064A440E for ; Wed, 2 Sep 2026 14:49:26 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=91.218.175.218 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788360569; cv=none; b=QLa+0nyzGgJrY4vHhLPZG0va0G1BW8LsJz3r6EDaYFLfRu7lp9DxthnRAW0tEtYiuduJIocPAjwhCz+0dcjJVzKyzD+8TlS6SJ8xebgx+ijKtzf5WSdEg9Fkee3Xrgcj0VtthwH7Rr6Z/h2UDzmTl0VHm2xsDFwkiJS0QKk2aI0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788360569; c=relaxed/simple; bh=PNTYEsienLPJUy1uoqn4OKAXtUVXa5IiTiSzsYklAZw=; h=MIME-Version:Date:Content-Type:From:Message-ID:Subject:To:Cc: In-Reply-To:References; b=jJ49AfCYRW0PF5YkTIV9UExwLdpCFk5+aUvb/5yeuSeutfTWvb9A5FoMYF486gUyibe55S7jsTcptAC6hQLZp6NRpVN8MnkTJ2wCfKf/okBAX/yOAC4zkabLKwFtb11HgZALz/BFrshXEg9FUuDubyBS05pz1Dfv/P1vFHL84HM= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b=jUagR789; arc=none smtp.client-ip=91.218.175.218 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b="jUagR789" X-Envelope-To: linux-kernel@vger.kernel.org DKIM-Signature: a=rsa-sha256; bh=PNTYEsienLPJUy1uoqn4OKAXtUVXa5IiTiSzsYklAZw=; c=simple/simple; d=linux.dev; h=from:to:subject:date:message-id:mime-version:content-type; s=key1; t=1788360564; v=1; x=1788965364; b=jUagR789yRGahvWwsgQXiUG58bR+xrlRnzuKn6JisQPPYt7DHLQy0RyzGtZCqqCpYnd3h9mD q2BMoXjz+/RmxXGilozq7jJT8vDNo1+gjP8dSBDDbekbPE3SnUSLVzXTzP3BCjZIdJRGSClG6Kc ugXws4UDIgrOFb1/Abhbg7I4= X-Envelope-To: linux-kernel@vger.kernel.org Received: by smtp.migadu.com with ESMTPS id 3fe4aa4587650eab; Wed, 02 Sep 2026 14:49:14 +0000 X-Mizu-Trace-ID: 3fe4aa4587650eab X-Migadu-Flow: FLOW_OUT Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Date: Wed, 02 Sep 2026 14:49:14 +0000 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: "Zqiang" Message-ID: <2ff0e6ca8e1e05078a69dbd2b2ccd1e62fc4650f@linux.dev> TLS-Required: No Subject: Re: [PATCH] dlm: wait for outstanding SRCU callbacks to complete in exit paths To: "Alexander Aring" Cc: teigland@redhat.com, gfs2@lists.linux.dev, linux-kernel@vger.kernel.org, rcu@vger.kernel.org In-Reply-To: References: <20260901091836.16906-1-qiang.zhang@linux.dev> >=20 >=20Hi, >=20 >=20On Wed, Sep 2, 2026 at 10:30 AM Zqiang wrote: >=20 >=20>=20 >=20> > > > > Hi, > > > > > > On Tue, Sep 1, 2026 at 5:19 AM Zqiang wrot= e: > > > > > > > > > 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. Whe= n > > > such a callback finally runs, it executes freed module code and > > > touches the static SRCU domains that are being torn down, resultin= g > > > in a use-after-free. > >=20 >=20> I should rephrase it: > >=20 >=20> Due to missed call to the srcu_barrier(), when invoke cleanup_srcu= _struct() > >=20 >=20Then 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 b= efore 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 wa= it the all call_rcu() to complete, because rcu_barrier() which in dlm_memory_exit() = is required to successfully intercept these RCU callbacks. Thanks Zqiang >=20 >=20I am confused here. >=20 >=20- Alex >