linux-kernel - Re: [PATCH] lto: Add __noreorder and mark initcalls _

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, 8 Apr 2015 15:31:12 -0700
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	Andi Kleen <andi@...stfloor.org>
Cc:	mmarek@...e.cz, linux-kbuild@...r.kernel.org,
	linux-kernel@...r.kernel.org, Andi Kleen <ak@...ux.intel.com>
Subject: Re: [PATCH] lto: Add __noreorder and mark initcalls __noreorder

On Wed,  8 Apr 2015 06:17:38 -0700 Andi Kleen <andi@...stfloor.org> wrote:

> From: Andi Kleen <ak@...ux.intel.com>
> 
> gcc 5 has a new no_reorder attribute that prevents top level
> reordering only for that symbol.

I'm having trouble locating gcc documentation which explains all this
stuff.

> Kernels don't like any reordering of initcalls between files, as several
> initcalls depend on each other. LTO previously needed to use
> -fno-toplevel-reordering to prevent boot failures.

That's "-fno-toplevel-reorder", I believe?

> Add a __noreorder wrapper for the no_reorder attribute and use
> it for initcalls.

Head is spinning a bit.  As this all appears to be shiny new
added-by-andi gcc functionality, it would be useful if we could have a
few more words describing what it's all about.  Reordering of what with
respect to what and why and why is it bad.  Why is gcc reordering
things anyway, and what's the downside of preventing this.  Why is the
compiler reordering things rather than the linker. etc etc etc.

Please gently educate us ;)

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