Re: [PATCH x86] [15/16] Force __cpuinit on for CONFIG_PM withoutHOTPLUG_CPU

[Adrian Bunk]

On Tue, Jan 15, 2008 at 06:11:46PM +0100, Andi Kleen wrote:
> On Tue, Jan 15, 2008 at 05:25:13PM +0100, Sam Ravnborg wrote:
> > On Tue, Jan 15, 2008 at 04:17:42PM +0100, Ingo Molnar wrote:
> > > 
> > > * Sam Ravnborg <sam@xxxxxxxxxxxx> wrote:
> > > 
> > > > > find below the current set of warnings on -git. There are 62.
> > > > 
> > > > The correct figure is 112.
> > > > 
> > > > You need to do a:
> > > > make KCFLAGS=-fno-unit-at-a-time
> > > > build to see them all.
> > > 
> > > btw., please add a .config option to trigger the -fno-unit-at-a-time 
> > > flags. Something like CONFIG_SECTION_ERRORS=y - plus perhaps combine it 
> > > with the patch below that turns such section bugs into detectable build 
> > > errors. A distro does not want to build a kernel that could potentially 
> > > corrupt kernel memory. (it's a security risk as well.) If we make the 
> > > err=1 dependent on CONFIG_SECTION_ERRORS then we'll have this 
> > > configurable.
> > 
> > The plan is to let section mismatch warnings become errors 
> > after the merge window - so we hit -mm first.
> 
> A lot of those I look at seem to be not really bugs;

Half of them are possible Oopses, and the other half are about wasted 
memory.

The warnings in the kernel that are not really bugs you can count with 
your fingers.

> also my
> impression is that they sometimes crop up randomly. e.g. you
> change something completely unrelated and suddenly you get
> a section warning somewhere else.
>...

Not all errors are always visible, they might depend on CONFIG_ 
options, and sometimes gcc optimizes such bugs away.

> -Andi

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/