lkml.org 
[lkml]   [2012]   [Feb]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Linux 3.3-rc4
On 02/20/2012 09:06 PM, Linus Torvalds wrote:
> On Mon, Feb 20, 2012 at 8:52 PM, Ian Kent <raven@themaw.net> wrote:
>>
>> I think the patch attached to your original post needs a little work if
>> that is to be used. Correct me if I'm wrong but AFAICT there are more
>> architectures that use 8-byte alignment than just x86-64, such as alpha,
>> ia64 and ppc64 and I believe they may also be used in a compat mode.
>
> The only issue is compat mode, and afaik, all other architectures
> except for x86-32 do __u64 with natural alignment.
>
> So all 64-bit architectures use natural alignment, the only issue is
> the alignment of __u64 in 32-bit mode.
>
> So it really is *not* about 8-byte alignment. Quite the reverse. It's
> about 4-byte alignment of 64-bit entities, and I suspect x86-32 is the
> only one that does that.
>
> See "compat_u64", and notice how only in arch/x86/include/asm/compat.h
> do we have
>
> typedef u64 __attribute__((aligned(4))) compat_u64;
>
> So it really is limited to only x86.
>

m68k has alignment 2 for 32- and 64-bit quantities, so it's not just
x86; the only reason you don't see that one is because m68k doesn't have
a compat layer to worry about.

Holes are highly undesirable for another reason: they create security
holes where kernel information leaks out.

-hpa


--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.



\
 
 \ /
  Last update: 2012-02-21 06:31    [W:0.068 / U:0.436 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site