linux-kernel - Re: Section mismatch on latest git

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: <20080530072816.GA26169@uranus.ravnborg.org>
Date:	Fri, 30 May 2008 09:28:16 +0200
From:	Sam Ravnborg <sam@...nborg.org>
To:	Randy Dunlap <randy.dunlap@...cle.com>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Fabio Comolli <fabio.comolli@...il.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: Section mismatch on latest git

On Thu, May 29, 2008 at 09:38:45PM -0700, Randy Dunlap wrote:
> On Thu, 29 May 2008 00:01:28 -0700 Andrew Morton wrote:
> 
> > On Mon, 26 May 2008 10:03:21 +0200 "Fabio Comolli" <fabio.comolli@...il.com> wrote:
> > 
> > > Hi.
> > > I don't know it it has been reported already:
> > > 
> > > WARNING: vmlinux.o(.text+0x114bb): Section mismatch in reference from
> > > the function nopat() to the function .cpuinit.text:pat_disable()
> > > The function nopat() references
> > > the function __cpuinit pat_disable().
> > > This is often because nopat lacks a __cpuinit
> > > annotation or the annotation of pat_disable is wrong.
> > > 
> > > Config is in attachment.
> > > 
> > 
> > This should fix it:
> > 
> > --- a/arch/x86/mm/pat.c~arch-x86-mm-patc-nopat-should-be-__init
> > +++ a/arch/x86/mm/pat.c
> > @@ -34,7 +34,7 @@ void __cpuinit pat_disable(char *reason)
> >  	printk(KERN_INFO "%s\n", reason);
> >  }
> >  
> > -static int nopat(char *str)
> > +static int __init nopat(char *str)
> >  {
> >  	pat_disable("PAT support disabled.");
> >  	return 0;
> > _
> > 
> > 
> > It turns out that this was harmless.  However it might not have been -
> > I think that adding the ability to suppress all these warnings was a
> > mistake.  
> 
> It certainly has caused me to stop looking for/at them.
> More a sin of omission than one of commission.

My plan in this area is:
- Get my dev box operational again (awaiting spare parts from Intel)
- Get usual configs warning free (or almost warning free)
- Enable the warning in kbuild-next.git right after -rc1

As my dev box is down atm I have prioritized what I conviniently
can do on my mail-box (no defconfig/all*config builds).

	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/