linux-kernel - Re: [PATCH] FLAT: allow arches to declare a larger alignment than the slab

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:	Wed, 26 May 2010 03:36:30 -0400
From:	Mike Frysinger <vapier.adi@...il.com>
To:	Paul Mundt <lethal@...ux-sh.org>
Cc:	Jie Zhang <jie@...esourcery.com>, uclinux-dev@...inux.org,
	David Howells <dhowells@...hat.com>,
	David McCullough <davidm@...pgear.com>,
	Greg Ungerer <gerg@...inux.org>,
	uclinux-dist-devel@...ckfin.uclinux.org,
	microblaze-uclinux@...e.uq.edu.au, Michal Simek <monstr@...str.eu>,
	linux-m32r@...linux-m32r.org,
	Hirokazu Takata <takata@...ux-m32r.org>,
	linux-kernel@...r.kernel.org,
	Yoshinori Sato <ysato@...rs.sourceforge.jp>
Subject: Re: [PATCH] FLAT: allow arches to declare a larger alignment than the 
	slab

On Tue, May 25, 2010 at 22:23, Jie Zhang wrote:
> On 05/26/2010 07:17 AM, Mike Frysinger wrote:
>> i do not believe that is the reason for this, but unfortunately Jie is
>> about the only one atm who knows the inner details as for why shared
>> FLAT libraries requires 0x20 rather than just 0x4 alignment.  i do
>> know that there are some gcc fortran tests that fail otherwise.
>> hopefully he can remember details ;).
>
> I encountered this issue when investigating some GCC test failures when
> using FLAT. I don't remember if they were in GCC Fortran testsuite. Some
> variables in those test cases were required to be aligned at a large
> boundary, for example 16-byte. I found 0x20 was a reasonably large alignment
> to fix all such failures in GCC testsuite.

ok, i found the reports Jie worked on originally.  the 0x20 value isnt
a hardware restriction or anything.  some gcc tests use the alignment
directive and then double check that it was respected.  the way the
FLAT loader crams things into the start of the data page before
appending the data breaks this.  so 0x20 was selected because, as Jie
said, it seemed to satisfy all of the gcc tests.

presumably this issue could be resolved by changing the FLAT loader to
append this internal state data instead of prepending.  that would fix
FLAT behavior wrt alignment directives (up to a page).
-mike
--
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/