linux-kernel - Re: [PATCH x86] [15/16] Force __cpuinit on for CONFIG_PM without HOTPLUG

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]

Message-ID: <20080115183132.GD18338@uranus.ravnborg.org>
Date:	Tue, 15 Jan 2008 19:31:32 +0100
From:	Sam Ravnborg <sam@...nborg.org>
To:	Andi Kleen <andi@...stfloor.org>
Cc:	Ingo Molnar <mingo@...e.hu>, Adrian Bunk <bunk@...nel.org>,
	rjw@...k.pl, pavel@...e.cz, linux-kernel@...r.kernel.org
Subject: Re: [PATCH x86] [15/16] Force __cpuinit on for CONFIG_PM without HOTPLUG_CPU

On Tue, Jan 15, 2008 at 07:29:04PM +0100, Andi Kleen wrote:
> On Tue, Jan 15, 2008 at 07:21:42PM +0100, Sam Ravnborg wrote:
> > With default options to gcc my .config produces ~65 warnings
> > but with -fno-unit-a-time I get 112 warnings.
> > Solely due to less inlining done by gcc.
> > 
> > So there are two sources for the 'randomization':
> > a) The actual config
> > b) The sometimes agressive inlining
> 
> Inlining should not be random.  And how does inlining cause such a warning?
Consider:

static int __init foo()
{
	// ...
}

static int bar()
{
	// ...
	if (foo())
		// ...
}

gcc will often inline foo into bar - and then all code are suddenly
part of .text and no section mismatch.
But you add anohter call to foo() somewhere so gcc decide no longer
to inline foo() and we then have a reference from .text to .init.text.

> > 
> > a) will be addressed by having separate sections for each
> > __init* type that is at link time combined where it belongs.
> 
> One problem I ran into the past was that older binutils seem
> to have some exponential behaviour with a lot of named sections
> and run very slowly.
This is more the -ffunction-section issue I guess.
What we are dealig with here is ~20 more sections and the kernel has
~100 section today (or more). So not a huge increase.

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