From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sg-3-112.ptr.tlmpb.com (sg-3-112.ptr.tlmpb.com [101.45.255.112]) (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 9A83C2E8B67 for ; Mon, 8 Jun 2026 03:29:01 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=101.45.255.112 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780889344; cv=none; b=Y11raTz9CE77OvLxbUIBjbL5CPjjYUQe54yB3HuWQNlWAJMEMlczeiqyM9SU1aajHCivu9hM+bhct3cUUwsB+JdVenHzwT/wZITe6Ey4nVDGubqVB5gojErzG6ffquy3jEnHaJNCxOuCr6vb6TRVx4yxXI16gM+kW/dwhrfFVJs= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780889344; c=relaxed/simple; bh=3p21nhULlOFap4CtEJAN7xI98sP0bCHb96zjeXMO1QA=; h=Date:In-Reply-To:From:Message-Id:Mime-Version:Content-Type:Cc: Subject:To:References; b=AsmySBuGUjuly2lMVcubw21evX0TA6qw5qwQZsSIHwL4ejgQ5l7d33UWpCMZ/a91qNU3KTNBlrZdTXKko+mOIhtGzCSSti7TGn2mxqOahMM1aCRO0muSfzeJ6jcjYjTUPG87EIZvj9gBcrqEYVFgsoLIeFoVTXPvem2NZNONdag= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=bytedance.com; spf=pass smtp.mailfrom=bytedance.com; dkim=pass (2048-bit key) header.d=bytedance.com header.i=@bytedance.com header.b=BfkpkB2z; arc=none smtp.client-ip=101.45.255.112 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=bytedance.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=bytedance.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=bytedance.com header.i=@bytedance.com header.b="BfkpkB2z" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; s=2212171451; d=bytedance.com; t=1780889290; h=from:subject: mime-version:from:date:message-id:subject:to:cc:reply-to:content-type: mime-version:in-reply-to:message-id; bh=BnFRpGMvMTrAbPzGLBDo0aZKDmaAWW1kmVRIz1TflEw=; b=BfkpkB2zKqjHUheb/apaxY9N2rtOqNugX8egPus6VhQI66MJPMJXIM3q7bCyQXjNefzEUT jE+H7YLdGCIMMeVGkSwG8AV+eynNjot/UMPiw3WRmkBM7fji49wWN64NQs8KCn+8MVIPyn 1m7jnz9uj4wSzKXJDSDloGirpjkPyU8G3oFFiebfft2Q7wwZkqF5FRfvsg46YQ9gLRC88A ofR1tCmYse6it38CKCm+28Xs2aF/lvbgPG+f7zOxSYeuSNZr62CkIfL6IFpwVBtRYMa3ao 3GUmDS5OxVg3Ed8hl9WVXqfKWXlWBeGVMi7pS4Ok7SAydMhhELyycWoK0IHmcA== Date: Mon, 8 Jun 2026 11:27:54 +0800 X-Original-From: Rui Qi In-Reply-To: <20260525063235.990101-1-qirui.001@bytedance.com> From: "Rui Qi" Message-Id: <20260608112000.1-qirui.001@bytedance.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 X-Mailer: git-send-email 2.20.1 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=UTF-8 Cc: "Rui Qi" , , , , "Greg Kroah-Hartman" Subject: Re: [PATCH v2] ipmi: Fix rcu_read_unlock to srcu_read_unlock in handle_read_event_rsp X-Lms-Return-Path: To: "Corey Minyard" References: <20260525063235.990101-1-qirui.001@bytedance.com> Hi Corey, I'm following up on this patch which was originally submitted on March 25 and resubmitted as v2 on May 25. I haven't received any feedback so far, so I wanted to bring it back to your attention. To recap, this is a one-line fix for handle_read_event_rsp() where rcu_read_unlock() is incorrectly called instead of srcu_read_unlock() on the error path, leaving the SRCU read-side lock held. This patch is specifically targeted at stable branches (v6.12 and earlier) that still carry the original SRCU-based locking. In mainline, commit 3be997d5a64a ("ipmi:msghandler: Remove srcu from the ipmi user structure") has already restructured this function to use a mutex, effectively eliminating the bug. However, that commit is part of a larger SRCU removal series that is not suitable for stable backport. Since the affected code no longer exists in mainline or your for-next tree, this patch cannot follow the usual path of being applied there first and then cherry-picked by stable. Could you please review and provide an Acked-by so the stable team can pick it up directly? No changes since v2. The patch is reproduced below for convenience. From: Rui Qi Subject: [PATCH v2] ipmi: Fix rcu_read_unlock to srcu_read_unlock in handle_read_event_rsp Fix a bug where rcu_read_unlock() was used instead of srcu_read_unlock() in handle_read_event_rsp() when ipmi_alloc_recv_msg() fails. This mismatch leads to an SRCU read-side critical section imbalance: the entry uses srcu_read_lock(&intf->users_srcu) but the error path incorrectly calls rcu_read_unlock(), which is a no-op for SRCU and leaves the SRCU lock held. The offending code was restructured in mainline by commit 3be997d5a64a ("ipmi:msghandler: Remove srcu from the ipmi user structure"), which replaced the SRCU locking with a mutex in this function, effectively eliminating the mismatch. However, that commit is part of a larger SRCU removal series that is not suitable for stable backport. This minimal fix addresses the SRCU imbalance for 6.12 and earlier stable branches that still carry the original locking scheme. Fixes: e86ee2d44b44 ("ipmi: Rework locking and shutdown for hot remove") Cc: stable@vger.kernel.org Signed-off-by: Rui Qi drivers/char/ipmi/ipmi_msghandler.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/char/ipmi/ipmi_msghandler.c b/drivers/char/ipmi/ipmi_msghandler.c index 188722ec0337..41ae4dac4eeb 100644 --- a/drivers/char/ipmi/ipmi_msghandler.c +++ b/drivers/char/ipmi/ipmi_msghandler.c @@ -4395,7 +4395,7 @@ static int handle_read_event_rsp(struct ipmi_smi *intf, recv_msg = ipmi_alloc_recv_msg(user); if (IS_ERR(recv_msg)) { - rcu_read_unlock(); + srcu_read_unlock(&intf->users_srcu, index); list_for_each_entry_safe(recv_msg, recv_msg2, &msgs, link) { list_del(&recv_msg->link);