All of lore.kernel.org
 help / color / mirror / Atom feed
From: YingChi Long <me@inclyc.cn>
To: me@inclyc.cn
Cc: bp@alien8.de, chang.seok.bae@intel.com,
	dave.hansen@linux.intel.com, hpa@zytor.com,
	linux-kernel@vger.kernel.org, mingo@redhat.com,
	ndesaulniers@google.com, pbonzini@redhat.com, tglx@linutronix.de,
	x86@kernel.org, david.laight@aculab.com
Subject: [PATCH v3] x86/fpu: use _Alignof to avoid UB in TYPE_ALIGN
Date: Thu,  6 Oct 2022 22:14:42 +0800	[thread overview]
Message-ID: <20221006141442.2475978-1-me@inclyc.cn> (raw)
In-Reply-To: <20220925153151.2467884-1-me@inclyc.cn>

WG14 N2350 made very clear that it is an UB having type definitions with
in "offsetof". This patch change the implementation of macro
"TYPE_ALIGN" to builtin "_Alignof" to avoid undefined behavior.

I've grepped all source files to find any type definitions within
"offsetof".

    offsetof\(struct .*\{ .*,

This implementation of macro "TYPE_ALIGN" seemes to be the only case of
type definitions within offsetof in the kernel codebase.

I've made a clang patch that rejects any definitions within
__builtin_offsetof (usually #defined with "offsetof"), and tested
compiling with this patch, there are no error if this patch applied.

ISO C11 _Alignof is subtly different from the GNU C extension
__alignof__. __alignof__ is the preferred alignment and _Alignof the
minimal alignment. For 'long long' on x86 these are 8 and 4
respectively.

The macro TYPE_ALIGN we're replacing has behavior that matches
_Alignof rather than __alignof__.

Signed-off-by: YingChi Long <me@inclyc.cn>
Link: https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2350.htm
Link: https://godbolt.org/z/sPs1GEhbT
Link: https://gcc.gnu.org/onlinedocs/gcc/Alignment.html
Link: https://reviews.llvm.org/D133574
---
v3:
- commit message changes suggested by Nick and David

v2: https://lore.kernel.org/all/20220927153338.4177854-1-me@inclyc.cn/
---
 arch/x86/kernel/fpu/init.c | 7 ++-----
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/arch/x86/kernel/fpu/init.c b/arch/x86/kernel/fpu/init.c
index 621f4b6cac4a..de96c11e1fe9 100644
--- a/arch/x86/kernel/fpu/init.c
+++ b/arch/x86/kernel/fpu/init.c
@@ -133,9 +133,6 @@ static void __init fpu__init_system_generic(void)
 	fpu__init_system_mxcsr();
 }

-/* Get alignment of the TYPE. */
-#define TYPE_ALIGN(TYPE) offsetof(struct { char x; TYPE test; }, test)
-
 /*
  * Enforce that 'MEMBER' is the last field of 'TYPE'.
  *
@@ -143,8 +140,8 @@ static void __init fpu__init_system_generic(void)
  * because that's how C aligns structs.
  */
 #define CHECK_MEMBER_AT_END_OF(TYPE, MEMBER) \
-	BUILD_BUG_ON(sizeof(TYPE) != ALIGN(offsetofend(TYPE, MEMBER), \
-					   TYPE_ALIGN(TYPE)))
+	BUILD_BUG_ON(sizeof(TYPE) !=         \
+		     ALIGN(offsetofend(TYPE, MEMBER), _Alignof(TYPE)))

 /*
  * We append the 'struct fpu' to the task_struct:
--
2.35.1


  parent reply	other threads:[~2022-10-06 14:18 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-25 15:31 [PATCH] x86/fpu: use __alignof__ to avoid UB in TYPE_ALIGN YingChi Long
2022-09-26  9:01 ` Peter Zijlstra
2022-09-26 13:18   ` YingChi Long
2022-09-26 19:02     ` Nick Desaulniers
2022-09-27  8:20     ` David Laight
2022-09-27 15:33 ` [PATCH v2] x86/fpu: use _Alignof " YingChi Long
2022-09-27 15:58   ` David Laight
2022-09-27 16:44     ` YingChi Long
2022-09-27 17:07       ` YingChi Long
2022-09-28  8:09       ` David Laight
2022-09-28 11:23         ` YingChi Long
2022-10-05  7:29   ` YingChi Long
2022-10-05 18:30     ` Nick Desaulniers
2022-10-05 18:38       ` Nick Desaulniers
2022-10-05 18:57         ` Nick Desaulniers
2022-10-06  8:12           ` David Laight
2022-10-06 14:14 ` YingChi Long [this message]
2022-10-06 17:34   ` [PATCH v3] " Nick Desaulniers
2022-10-18  0:52   ` YingChi Long
2022-10-29 12:25   ` [PATCH RESEND " YingChi Long
2022-10-31 18:29     ` Nick Desaulniers
2022-11-02 16:55     ` Borislav Petkov
2022-11-02 18:07       ` YingChi Long
2022-11-02 18:14       ` [PATCH v4] " YingChi Long
2022-11-02 21:41       ` [PATCH RESEND v3] " David Laight
2022-11-18  0:55       ` [PATCH RESEND v4] " Yingchi Long
2022-11-22 16:26 ` [tip: x86/fpu] x86/fpu: Use _Alignof to avoid undefined behavior " tip-bot2 for YingChi Long

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=20221006141442.2475978-1-me@inclyc.cn \
    --to=me@inclyc.cn \
    --cc=bp@alien8.de \
    --cc=chang.seok.bae@intel.com \
    --cc=dave.hansen@linux.intel.com \
    --cc=david.laight@aculab.com \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=ndesaulniers@google.com \
    --cc=pbonzini@redhat.com \
    --cc=tglx@linutronix.de \
    --cc=x86@kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.