linux-kernel - Re: [xfs-masters] [PATCH] fs: Add new pre-allocation ioctls to vfs for compatibility with legacy xfs ioctls

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 02 Feb 2009 11:33:59 +0200
From:	Boaz Harrosh <bharrosh@...asas.com>
To:	Geert Uytterhoeven <geert@...ux-m68k.org>
CC:	Arnd Bergmann <arnd@...db.de>,
	Christoph Hellwig <hch@...radead.org>,
	Eric Sandeen <sandeen@...deen.net>, mfasheh@...e.com,
	joel.becker@...cle.com, linux-kernel@...r.kernel.org,
	xfs-masters@....sgi.com, viro@...iv.linux.org.uk,
	Ankit Jain <me@...itjain.org>, linux-fsdevel@...r.kernel.org,
	Andrew Morton <akpm@...ux-foundation.org>, xfs@....sgi.com,
	ocfs2-devel@....oracle.com
Subject: Re: [xfs-masters] [PATCH] fs: Add new pre-allocation ioctls to vfs
 for compatibility with legacy xfs ioctls

Geert Uytterhoeven wrote:
> On Mon, 2 Feb 2009, Boaz Harrosh wrote:
>> Arnd Bergmann wrote:
>>> No, the compiler is correct, it has to generate more complex code
>>> if it cannot assume that data is naturally aligned and the architecture
>>> does not support unaligned loads. If you don't understand this, please
>>> at least read the list archives about the last five times this came up
>>> before claiming that the compiler is broken.
>>>
>> Wrong!! Sorry, you guys don't listen.
>> I'm talking of the case where the structures are EXACTLY the same anyway
>> you look at them. sizeof(foo) == sizeof(foo_packed) and 
>> offsetof(foo_memmber) == offsetof(foo_packed_member) for every member of
>> the structure. foo && foo_packed are declared exactly the same but with
>> __attribute__((packed(1))) applied to the later.
>>
>> THEN in ia64 case the compiler is brain dead, because it relates
>> "unalignment" to packed(1) which are two different things.
> 
> The natural alignment of a structure is max(alignment(member)), for all
> members. With __attribute__((packed)), the natural alignment of the structure
> is 1, so the compiler cannot assume anything.
> 

No the natural alignment is what it is, after the application of
__attribute__((packed(1))). In a well defined structure that is a no-opt.
But yes in ai64 the gcc programmers got lazy and did not make that analysis
after laying out the structure.

> While the ints in the structure may still be at offsets 0, 4, 8, and so on,
> this doesn't say anything about their actual memory addresses, as the struct
> base address itself may be unaligned.
> 

The base address can be unaligned even if the structure is aligned. In that
case you need the __atrubute__((aligned)) thingy. It is true that if the sizeof(foo_packed)
is though unaligned, the compiler will have to assume unalignment in array operations.
but if the sizeof(foo_packed) is naturally aligned at the output then the compiler
has all the needed information to know that even if I declared __packed, it calculated
and knows that it is well aligned at the end.

> Gr{oetje,eeting}s,
> 
> 						Geert
> 

Please note that I gave up on the compiler and understand that the use of __packed
is dangerous in some cases, sigh. My standing point is to make sure there are no guesses
left, and a BUILD_BUG_ON to make sure of that.

Boaz
--
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/