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
Dave
--
http://www.codemonkey.org.uk
Dave Jones <[email protected]> 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?
On Sat, Mar 25, 2006 at 11:50:35PM -0800, Andrew Morton wrote:
> Dave Jones <[email protected]> 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).
Dave
--
http://www.codemonkey.org.uk
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 <[email protected]> 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
On Sun, Mar 26, 2006 at 06:10:55PM +0200, Sam Ravnborg wrote:
> 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.
Finally coaxed latest -git to build on all archs I care about..
grab http://people.redhat.com/davej/buildlog.txt and grep for WARNING:
and see a zillion errors. The smp_locks ones seem to have disappeared
now though.
Dave
--
http://www.codemonkey.org.uk
On Mon, 27 Mar 2006 19:04:18 -0500 Dave Jones wrote:
> On Sun, Mar 26, 2006 at 06:10:55PM +0200, Sam Ravnborg wrote:
>
> > 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.
>
> Finally coaxed latest -git to build on all archs I care about..
> grab http://people.redhat.com/davej/buildlog.txt and grep for WARNING:
> and see a zillion errors. The smp_locks ones seem to have disappeared
> now though.
I just posted a boatload of them to the kernel-janitors m-l also.
---
~Randy
On Sun, Mar 26, 2006 at 06:10:55PM +0200, Sam Ravnborg wrote:
> On Sun, Mar 26, 2006 at 10:40:42AM -0500, Dave Jones wrote:
> >
> > 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.
>...
This doesn't sound good.
This means that we have no longer any tool that warns us about e.g.
references from non-__exit code to __exit code [1]?
> Sam
cu
Adrian
[1] __exit, not __{dev,cpu,mem}exit
--
"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
On Fri, Mar 31, 2006 at 09:08:51PM +0200, Adrian Bunk wrote:
> On Sun, Mar 26, 2006 at 06:10:55PM +0200, Sam Ravnborg wrote:
> > On Sun, Mar 26, 2006 at 10:40:42AM -0500, Dave Jones wrote:
> > >
> > > 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.
> >...
>
> This doesn't sound good.
>
> This means that we have no longer any tool that warns us about e.g.
> references from non-__exit code to __exit code [1]?
> [1] __exit, not __{dev,cpu,mem}exit
It does warn for this also. The test I have carried out has mostly been
on allmodconfig builds though. I assume you are worried for the case
when a module is built-in and the __exit section is discarded - or?
Sam
On Fri, Mar 31, 2006 at 09:33:38PM +0200, Sam Ravnborg wrote:
> On Fri, Mar 31, 2006 at 09:08:51PM +0200, Adrian Bunk wrote:
> > On Sun, Mar 26, 2006 at 06:10:55PM +0200, Sam Ravnborg wrote:
> > > On Sun, Mar 26, 2006 at 10:40:42AM -0500, Dave Jones wrote:
> > > >
> > > > 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.
> > >...
> >
> > This doesn't sound good.
> >
> > This means that we have no longer any tool that warns us about e.g.
> > references from non-__exit code to __exit code [1]?
> > [1] __exit, not __{dev,cpu,mem}exit
>
> It does warn for this also. The test I have carried out has mostly been
> on allmodconfig builds though. I assume you are worried for the case
> when a module is built-in and the __exit section is discarded - or?
Exactly - especially since in kernel 2.6 we are getting on architectures
like i386 no longer link errors as we did in kernel 2.4.
Perhaps I'm only concerned because my usual builds didn't produce a
single warning... ;-)
> Sam
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