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 DE1AF417BC4 for ; Tue, 14 Jul 2026 18:19:05 +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=1784053146; cv=none; b=JTsD79GYK8nuV56ZnOyzokUiMJtz7ucm6u5cXUsGBkexL1tTNf9HqFD2NhGHJFV9j3xQW7Xu4vYAwKX3gtZdq+Hh0i/ml6zEtS1t3egc8C2H2vwkyUSbHQXGx19nkchnJ2z0BHq6U8e+mHXsLLKU6lZgfCDh3CfXLPNSa0AKvZk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784053146; c=relaxed/simple; bh=tddgcMy9iVy/+cOI7ac+iDbnj3RAGtGMrqo7hKgTTgs=; h=From:Subject:Date:Message-Id:MIME-Version:Content-Type:To:Cc; b=kh+eqTOvsDzYUAgeeHWcffMxC4rdM2qZ2rcHbyOTG0qALHZGOgLZEIUyWkWs1WysuFrg+znK4ZyTqVG74gQRdd+qKsx6dEuKBLC1VrOVQkgy3FOVB1HSdcHITTZkNb8aZNG3rm0MSSrBV3fCSfTyoyh9ljzM4ZY3zaXpc0+EyXs= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=hmKkKjeA; 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="hmKkKjeA" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4C85B1F000E9; Tue, 14 Jul 2026 18:19:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1784053145; bh=MX1jWJ1bF8cbQvSxkp+RvI1Gem3zPO3KuYx3MDLzqy8=; h=From:Subject:Date:To:Cc; b=hmKkKjeAr7LpJOsIRijv+veG7eb3mB6BJL6qLtMPisEwjcGz9XOilcfwHskN1klSu 5ZkCh5HmlDSTCXxVhxiAegkfQhVFOWgkfjA1yDjhWAGdj/T8oNkCdJnVH2NEumcRzk KeeKKJaRmlsjOg3cnHGEGFZcSVjnWUPtqtCRigT9nvsD5QwqQm/rnBRtO04sv6lvqH 5eh4cRpTb/l9HPgkIrZnlKE4aVAx2g34N6D8iNX+7XF0gHxQ8gjFz1aPfnRCAQKmQ/ wlw6pXWOdCFbvmYa4lstWL9WI46dxO/r73LSrOfZhrvGL0wGMxrhA1hp6+CSrpJn19 HR9aCOB5w0nxQ== From: Vincent Mailhol Subject: [PATCH 0/3] container_of: refactors Date: Tue, 14 Jul 2026 20:18:00 +0200 Message-Id: <20260714-containerof_refactor-v1-0-b5c31164d2ad@kernel.org> 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 X-B4-Tracking: v=1; b=H4sIAAAAAAAC/x2MQQqAIBAAvyJ7TnALQvpKRCy21l40Vokg+nvSc RhmHiiswgUm84DyJUVyaoCdgXBQ2tnK1hh6148O0dmQUyVJrDmuypFCzWrHgUL0iJ7QQ0vPZuT +t/Pyvh9dsJvFZgAAAA== X-Change-ID: 20260110-containerof_refactor-63acf8118a18 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=2572; i=mailhol@kernel.org; h=from:subject:message-id; bh=tddgcMy9iVy/+cOI7ac+iDbnj3RAGtGMrqo7hKgTTgs=; b=owGbwMvMwCV2McXO4Xp97WbG02pJDFlhtRMnP681Y5/BU9oYFP/P4eeT0mlJadz899fGNLuq8 LU62ad2TGRhEONisBRTZFlWzsmt0FHoHXboryXMHFYmkCHSIg0MQMDCwJebmFdqpGOkZ6ptqGcI ZOgYMXBxCsBUh/IxMuz50fC26VLZde0rdw//+uO3p2Vl1Kv1nWdFMo5bHxac/iqCkeFuaWtZue7 rU594N207Y+Z0+UHsyznFv4XWnpz00+Vj93peAA== X-Developer-Key: i=mailhol@kernel.org; a=openpgp; fpr=ED8F700574E67F20E574E8E2AB5FEB886DBB99C2 This series refactors the container_of() function-like macro to improve readability and remove a sparse/W=2 shadow warning. Further details in each patch. While I was expecting this series to be boring and purely cosmetic, the bloat-o-meter stats gave some unexpected results: $ ./scripts/bloat-o-meter vmlinux7.2-rc3_before.o vmlinux7.2-rc3_after.o add/remove: 0/0 grow/shrink: 133/93 up/down: 5914901/-14344137 (-8429236) < ... 227 lines redacted > Total: Before=2641674349, After=2633245113, chg -0.32% (done on v7.2-rc3 with GCC 15.3.0 on an x86_64 defconfig) Upon analysis, this change in size can be tracked down to places where container_of() is used in combination with __builtin_constant_p(). Here is a minimal reproducer: struct foo { int a; }; #define to_foo(a_ptr) container_of(a_ptr, struct foo, a) int f(int *a) { return __builtin_constant_p(to_foo(a)->a) || a; } The assembly code before this series...: xor eax, eax test rdi, rdi setne al ret ...and after: mov eax, 1 ret Link: https://godbolt.org/z/fenbGexjY __builtin_constant_p(to_foo(a)->a) evaluates to false but gives the optimiser the hint that pointer a is not NULL because of the assumption that no undefined behaviour occurs. With this, the expression: __builtin_constant_p(to_foo(a)->a) || a could be evaluated as true by the optimiser. But the small variation in container_of() makes it that the optimiser currently misses this optimisation but manages to do it after the simplification of patch #3 of this series. When __builtin_constant_p()'s argument is not trivially a compile time constant, the result of __builtin_constant_p() comes late in the evaluation process. And if it comes too late, after some other optimisations were already done, the compiler will not retry and simply miss these optimisations. Note that the above example is very fragile and the results shown in the godbolt link might not be reproducible under very small variations. Signed-off-by: Vincent Mailhol --- Vincent Mailhol (3): container_of: apply typeof_member() to container_of() container_of: remove useless pair of parentheses container_of: remove local __mptr variable include/linux/container_of.h | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) --- base-commit: a13c140cc289c0b7b3770bce5b3ad42ab35074aa change-id: 20260110-containerof_refactor-63acf8118a18 Best regards, -- Vincent Mailhol