[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150508142453.GC4137@pd.tnic>
Date: Fri, 8 May 2015 16:24:53 +0200
From: Borislav Petkov <bp@...en8.de>
To: Rasmus Villemoes <linux@...musvillemoes.dk>
Cc: Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>,
"H. Peter Anvin" <hpa@...or.com>, x86@...nel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH] x86: tell the world boot_params is 16-byte aligned
On Fri, May 08, 2015 at 03:42:33PM +0200, Rasmus Villemoes wrote:
> It doesn't matter much, but this disassembly makes me cry a little bit:
>
> ffffffff81f21223 <copy_bootdata>:
> ffffffff81f21223: 55 push %rbp
> ffffffff81f21224: 48 c7 c0 40 c2 02 82 mov $0xffffffff8202c240,%rax
> ffffffff81f2122b: 48 89 fe mov %rdi,%rsi
> ffffffff81f2122e: a8 01 test $0x1,%al
>
> The reason is that boot_params is defined with
> __attribute__((aligned(16))) in boot/main.c, but other translation
> units only see the packed attribute on the definition of struct
> boot_params, so assume the worst. Making the de facto alignment public
Wouldn't it be better if we put both attributes together, i.e.:
diff --git a/arch/x86/include/uapi/asm/bootparam.h b/arch/x86/include/uapi/asm/bootparam.h
index ab456dc233b5..d26953d896d2 100644
--- a/arch/x86/include/uapi/asm/bootparam.h
+++ b/arch/x86/include/uapi/asm/bootparam.h
@@ -155,7 +155,7 @@ struct boot_params {
__u8 _pad8[48]; /* 0xcd0 */
struct edd_info eddbuf[EDDMAXNR]; /* 0xd00 */
__u8 _pad9[276]; /* 0xeec */
-} __attribute__((packed));
+} __attribute__((packed, aligned(16)));
enum {
X86_SUBARCH_PC = 0,
---
so that they're concentrated in one place?
gcc seems to swallow it, I haven't checked the bloat decrease though,
when one would declare boot_params this way.
Thanks.
--
Regards/Gruss,
Boris.
ECO tip #101: Trim your mails when you reply.
--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists