From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id B55063CEB8F for ; Tue, 14 Jul 2026 18:19:16 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784053157; cv=none; b=r2Uq2s/6Rb0YINxFQVJhz09FjB3wzZM9hz/ati5O9gbb/TLI7D+EK0oEoYDY0ytX1nSQfQD2qhv5huSANgz8hAc5L8b7Uy1yU66H+qufJA6ThaSCjn8CAez+RFmZMQ2kj/RFObxbseUo3uUG5sEu9SWHRsvYhpDdacr9bybJ80I= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784053157; c=relaxed/simple; bh=7NFj/emOgsY9GEv/OH9A4u2qBwoVeXtzkgjhw7O2l3Q=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=kiFJCBOIuuDom1jSvxtvlgMX9ypl9hVF1JulPfK89ygs4wNyT24P4JMgZ1WzejT2qMYGfpLgtGVrT+IVstz2a4hB8cUh7iklx4wfIVtj7EAO0RlIDLD1CTX84N4nCVapPnsZhUU24mtEH+ZII14y69HIgKOLJ6KQwGywUA8C7lU= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=in9fYw6p; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="in9fYw6p" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 591541F00A3A; Tue, 14 Jul 2026 18:19:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1784053156; bh=gfmUBrKFDs66Cd7+EN9Qk8wgLF9gqj4Shou1+JcrIe8=; h=From:Date:Subject:References:In-Reply-To:To:Cc; b=in9fYw6puhWRXS9eU5dtx4S/3JHKB6xtHA2jyJPv+FFWfjkQ3izRedFD/Jg7tUy29 vaK6jaR1HoxrnxaNHrKs2/VjxBVTs8i0+gGGyFAXlkHYQsCvQOyHlOr7U2rwAHz01P dfxxeLmP0zPdxLWGic4w7AmzIdQ4E6GmiUfCMu8cX8QjhED5LwoRHdMpCQUllXI94p 8P10/64kBZ2QgnsJIRte8av0h+mO9S9AM3iGiXqWzSeXCvzBY/yIa4fExTUvnFywQ7 2PWqZ94n6pfsNZVfYHOCWpLkOs5QD9hYRxbFoQ/MNICh/LKeG3H+JPvznbKCWspw/+ lh5mIQfy1q60g== From: Vincent Mailhol Date: Tue, 14 Jul 2026 20:18:03 +0200 Subject: [PATCH 3/3] container_of: remove local __mptr variable Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20260714-containerof_refactor-v1-3-b5c31164d2ad@kernel.org> References: <20260714-containerof_refactor-v1-0-b5c31164d2ad@kernel.org> In-Reply-To: <20260714-containerof_refactor-v1-0-b5c31164d2ad@kernel.org> To: Greg Kroah-Hartman , Andrew Morton Cc: Rasmus Villemoes , Sakari Ailus , Nick Desaulniers , Alexander Lobakin , Arnd Bergmann , David Sterba , Ivo van Doorn , Alexey Dobriyan , linux-kernel@vger.kernel.org, Vincent Mailhol X-Mailer: b4 0.14.3 X-Developer-Signature: v=1; a=openpgp-sha256; l=2303; i=mailhol@kernel.org; h=from:subject:message-id; bh=7NFj/emOgsY9GEv/OH9A4u2qBwoVeXtzkgjhw7O2l3Q=; b=owGbwMvMwCV2McXO4Xp97WbG02pJDFlhtVNFGB7NPLtjdbeR+T3PFx3Vv2cKWpjdkm9X9FzL/ +SRx3+zjoksDGJcDJZiiizLyjm5FToKvcMO/bWEmcPKBDJEWqSBAQhYGPhyE/NKjXSM9Ey1DfUM gQwdIwYuTgGYaiVtRoYXW+ecNLqzeuP+Baw/sz0npuW4KWgw/uizMtViCvtuxS3D8N+BV2jeV9b lL+eXRM973qHQxb7BjV3m0J/pR/um5fldPs0EAA== X-Developer-Key: i=mailhol@kernel.org; a=openpgp; fpr=ED8F700574E67F20E574E8E2AB5FEB886DBB99C2 container_of() can be called in a nested manner to retrieve the grand parent structure as illustrated below: struct foo { int a; }; struct bar { struct foo foo; }; #define to_foo(a_ptr) container_of(a_ptr, struct foo, a) #define to_bar(a_ptr) container_of(to_foo(a_ptr), struct bar, foo) The issue is that the above construct will cause __mptr, the local variable of container_of(), to shadow itself because of the nested call. This then triggers a warning in sparse and W=2 builds. While this warning is benign, it still causes some overhead as proven by below list of commits in which people made local workarounds: - commit 7eab14de73a8 ("mdio, phy: fix -Wshadow warnings triggered by nested container_of()") - commit 8d8c3131248d ("clk: define to_clk_regmap() as inline function") - commit bfb972c5e1cb ("IB/verbs: avoid nested container_of()") - commit 093adbcedf12 ("btrfs: switch helper macros to static inlines in sysfs.h") - commit c1d35dfa0f7d ("rt2x00: Fix sparse warning on nested container_of()") (the list is probably not exhaustive). As a matter of fact, the local variable __mptr is only used once in container_of(). As such, it is not strictly needed. Inline that local __mptr variable to remove once and for all the risk of variable shadowing when nesting container_of() and prevent people from writing further local fixes. Signed-off-by: Vincent Mailhol --- include/linux/container_of.h | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/include/linux/container_of.h b/include/linux/container_of.h index 68153170db32..28db38e9ee3e 100644 --- a/include/linux/container_of.h +++ b/include/linux/container_of.h @@ -17,11 +17,10 @@ * Do not use container_of() in new code. */ #define container_of(ptr, type, member) ({ \ - void *__mptr = (void *)(ptr); \ static_assert(__same_type(*(ptr), typeof_member(type, member)) || \ __same_type(*(ptr), void), \ "pointer type mismatch in container_of()"); \ - (type *)(__mptr - offsetof(type, member)); }) + (type *)((void *)(ptr) - offsetof(type, member)); }) /** * container_of_const - cast a member of a structure out to the containing -- 2.54.0