mail archive of the barebox mailing list
 help / color / mirror / Atom feed
From: Ahmad Fatoum <a.fatoum@pengutronix.de>
To: barebox@lists.infradead.org
Cc: Ahmad Fatoum <a.fatoum@pengutronix.de>
Subject: [PATCH master] kbuild: Use -fzero-init-padding-bits=all
Date: Fri, 25 Apr 2025 15:38:49 +0200	[thread overview]
Message-ID: <20250425133849.2362142-1-a.fatoum@pengutronix.de> (raw)

This is a port of Linux commit dce4aab8441d285b9a78b33753e0bf583c1320ee:

|   Author:     Kees Cook <kees@kernel.org>
|   AuthorDate: Mon Jan 27 11:10:28 2025 -0800
|
|   GCC 15 introduces a regression in "= { 0 }" style initialization of
|   unions that Linux has depended on for eliminating uninitialized variable
|   contents. GCC does not seem likely to fix it[1], instead suggesting[2]
|   that affected projects start using -fzero-init-padding-bits=unions.
|
|   To avoid future surprises beyond just the current situation with unions,
|   enable -fzero-init-padding-bits=all when available (GCC 15+). This will
|   correctly zero padding bits in unions and structs that might have been
|   left uninitialized, and will make sure there is no immediate regression
|   in union initializations. As seen in the stackinit KUnit selftest union
|   cases, which were passing before, were failing under GCC 15:
|
|       not ok 18 test_small_start_old_zero
|       ok 29 test_small_start_dynamic_partial # SKIP XFAIL uninit bytes: 63
|       ok 32 test_small_start_assigned_dynamic_partial # SKIP XFAIL uninit bytes: 63
|       ok 67 test_small_start_static_partial # SKIP XFAIL uninit bytes: 63
|       ok 70 test_small_start_static_all # SKIP XFAIL uninit bytes: 56
|       ok 73 test_small_start_dynamic_all # SKIP XFAIL uninit bytes: 56
|       ok 82 test_small_start_assigned_static_partial # SKIP XFAIL uninit bytes: 63
|       ok 85 test_small_start_assigned_static_all # SKIP XFAIL uninit bytes: 56
|       ok 88 test_small_start_assigned_dynamic_all # SKIP XFAIL uninit bytes: 56
|
|   The above all now pass again with -fzero-init-padding-bits=all added.
|
|   This also fixes the following cases for struct initialization that had
|   been XFAIL until now because there was no compiler support beyond the
|   larger "-ftrivial-auto-var-init=zero" option:
|
|       ok 38 test_small_hole_static_all # SKIP XFAIL uninit bytes: 3
|       ok 39 test_big_hole_static_all # SKIP XFAIL uninit bytes: 124
|       ok 40 test_trailing_hole_static_all # SKIP XFAIL uninit bytes: 7
|       ok 42 test_small_hole_dynamic_all # SKIP XFAIL uninit bytes: 3
|       ok 43 test_big_hole_dynamic_all # SKIP XFAIL uninit bytes: 124
|       ok 44 test_trailing_hole_dynamic_all # SKIP XFAIL uninit bytes: 7
|       ok 58 test_small_hole_assigned_static_all # SKIP XFAIL uninit bytes: 3
|       ok 59 test_big_hole_assigned_static_all # SKIP XFAIL uninit bytes: 124
|       ok 60 test_trailing_hole_assigned_static_all # SKIP XFAIL uninit bytes: 7
|       ok 62 test_small_hole_assigned_dynamic_all # SKIP XFAIL uninit bytes: 3
|       ok 63 test_big_hole_assigned_dynamic_all # SKIP XFAIL uninit bytes: 124
|       ok 64 test_trailing_hole_assigned_dynamic_all # SKIP XFAIL uninit bytes: 7
|
|   All of the above now pass when built under GCC 15. Tests can be seen
|   with:
|
|       ./tools/testing/kunit/kunit.py run stackinit --arch=x86_64 \
|           --make_option CC=gcc-15
|
|   Clang continues to fully initialize these kinds of variables[3] without
|   additional flags.
|
|   Suggested-by: Jakub Jelinek <jakub@redhat.com>
|   Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118403 [1]
|   Link: https://lore.kernel.org/linux-toolchains/Z0hRrrNU3Q+ro2T7@tucnak/ [2]
|   Link: https://github.com/llvm/llvm-project/commit/7a086e1b2dc05f54afae3591614feede727601fa [3]
|   Reviewed-by: Nathan Chancellor <nathan@kernel.org>
|   Acked-by: Masahiro Yamada <masahiroy@kernel.org>
|   Link: https://lore.kernel.org/r/20250127191031.245214-3-kees@kernel.org
|   Signed-off-by: Kees Cook <kees@kernel.org>

A quick look at { 0 } usage in barebox shows that initializations of
struct nvme_command in drivers/nvme/host/core.c might be affected by
this, so better play it safe.

Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
---
 Makefile | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/Makefile b/Makefile
index 58335c249a72..2e3931ed7b37 100644
--- a/Makefile
+++ b/Makefile
@@ -759,6 +759,9 @@ endif
 # disable invalid "can't wrap" optimizations for signed / pointers
 KBUILD_CFLAGS	+= $(call cc-option,-fno-strict-overflow)
 
+# Explicitly clear padding bits during variable initialization
+KBUILD_CFLAGS += $(call cc-option,-fzero-init-padding-bits=all)
+
 # Make sure -fstack-check isn't enabled (like gentoo apparently did)
 KBUILD_CFLAGS  += $(call cc-option,-fno-stack-check)
 
-- 
2.39.5




                 reply	other threads:[~2025-04-25 15:22 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20250425133849.2362142-1-a.fatoum@pengutronix.de \
    --to=a.fatoum@pengutronix.de \
    --cc=barebox@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox