Date: Sun, 26 Mar 2006 18:10:55 +0200
From: Sam Ravnborg <sam@ravnborg.org>
To: Dave Jones <davej@redhat.com>, Andrew Morton <akpm@osdl.org>,
       linux-kernel@vger.kernel.org
Subject: Re: smp_locks reference_discarded errors
Message-ID: <20060326161055.GA4584@mars.ravnborg.org>
References: <20060325033948.GA15564@redhat.com> <20060325235035.5fcb902f.akpm@osdl.org> <20060326154042.GB13684@redhat.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20060326154042.GB13684@redhat.com>
User-Agent: Mutt/1.5.11
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1996
Lines: 41

On Sun, Mar 26, 2006 at 10:40:42AM -0500, Dave Jones wrote:
> On Sat, Mar 25, 2006 at 11:50:35PM -0800, Andrew Morton wrote:
>  > Dave Jones <davej@redhat.com> wrote:
>  > >
>  > > since the addition of smp alternatives, the following is occuring..
>  > > 
>  > > Error: ./drivers/md/md.o .smp_locks refers to 0000008c R_386_32          .exit.text
>  > > Error: ./drivers/usb/storage/libusual.o .smp_locks refers to 00000008 R_386_32          .exit.text
>  > > Error: ./net/802/psnap.o .smp_locks refers to 00000000 R_386_32          .exit.text
>  > > Error: ./drivers/pci/hotplug/ibmphp_hpc.o .smp_locks refers to 00000008 R_386_32          .exit.text
>  > > Error: ./drivers/pci/hotplug/ibmphp_hpc.o .smp_locks refers to 0000000c R_386_32          .exit.text
>  > > 
>  > > example .config at http://people.redhat.com/davej/kernel-2.6.16-i686-smp.config
>  > > 
>  > 
>  > I guess an atomic operation in __exit code will cause that.  down() and
>  > atomic_dec_and_test() in two cases.
>  > 
>  > I suspect most of these callsites are just wrongly coded - it's pretty
>  > unusual for __exit code to really need to lock anything - what is there to
>  > be racing against?
>  > 
>  > This is emitted by reference_discarded.pl?
> 
> came out of a 'make buildcheck' a day or two ago (the following day,
> Sam nuked reference_discarded.pl in favour of it being done
> magically somewhere else (I've not looked into how its done now).
The check is part of modpost now. modpost is only used when building
modules but that holds true for most builds anyway therefore I did not
move it to a separate executable.

Also the output from modpost provides a bit more info.
So output from fresh -linus kernel would make it easier to locate the
guilty stuff.

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