find_isa_irq_pin can't be __init
PATCH 1/1 find_isa_irq_pin can't be __init
As spotted by one of our Fedora users, we sometimes oops during shutdown (http://www.roberthancock.com/kerneloops.png)
because disable_IO_APIC() wants to call find_isa_irq_pin(), which we threw away during init.
arch/i386/kernel/io_apic.c renamed from arch/i386/kernel/io_apic.c~ +1 -1
@@ -745,7 +745,7 @@ static int __init find_irq_entry(int api/* * Find the pin to which IRQ[irq] (ISA) is connected */ -static int __init find_isa_irq_pin (int irq,int type) +static int find_isa_irq_pin (int irq,int type) {int i;
__init dependencies (was: Re: [PATCH] find_isa_irq_pin can't be )__init
Quoted 4 lines · Dave Jones
As spotted by one of our Fedora users, we sometimes oops during shutdown (http://www.roberthancock.com/kerneloops.png)
becausedisable_IO_APIC()wants to callfind_isa_irq_pin(), which we threw away during init.
I guess it's about time for a tool to autodetect __init dependencies?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: __init dependencies (was: Re: [PATCH] find_isa_irq_pin can't be )__init
Quoted 2 lines · Geert Uytterhoeven
I guess it's about time for a tool to autodetect
__initdependencies?
`make buildcheck' does this. Looks like nobody is using it.
Re: __init dependencies (was: Re: [PATCH] find_isa_irq_pin can't be )__init
Quoted 5 lines · Andrew Morton
Quoted 2 lines · Geert Uytterhoeven
I guess it's about time for a tool to autodetect
__initdependencies?`make buildcheck' does this. Looks like nobody is using it.
Actually, aparently I goofed, and that patch is only needed in our Fedora kernels. It won't hurt in mainline though, and I'll push the other bits after 2.6.9
Dave
Re: __init dependencies
In reply to Andrew MortonQuoted 6 lines · Andrew Morton
Quoted 1 line · Geert Uytterhoeven
I guess it's about time for a tool to autodetect
__initdependencies?`make buildcheck' does this. Looks like nobody is using it.
I have asked that one of the forever-building machines here (OSDL) do that.
I'll get back to that request....
Signature · 3 lines
~Randy MOTD: Always include version info. (Again. Sometimes I think ln -s /usr/src/linux/.config .signature)
Re: __init dependencies
Quoted 8 lines · Randy.Dunlap
Quoted 6 lines · Andrew Morton
Quoted 1 line · Geert Uytterhoeven
I guess it's about time for a tool to autodetect
__initdependencies?
Quoted 6 lines
Quoted 1 line
`make buildcheck' does this. Looks like nobody is using it.
I have asked that one of the forever-building machines here (OSDL) do that.
I'll get back to that request....
John Cherry has been running 'make buildcheck' regularly, but apparently nobody has been looking.
Latest (2.6.9-rc4) is here:
http://developer.osdl.org/cherry/compile/2.6/linux-2.6.9-rc4.results/2.6.9-rc4.reference_init26.bzImage.txt
My experience with output of buildcheck is that it's verbose and has lots of false positives. (Yes, I have used it and generated patches from it.) First thing I do is delete all lines that match "data.*init" or "data.*exit". These are (usually -- famous word) OK. Then someone can look at the entries that really need to be checked, such as this list, derived from the larger list above:
http://developer.osdl.org/rddunlap/doc/2.6.9-rc4.reference_init26.bzImage.txt
I'll look over it in the next few days.
Signature · 1 line
~Randy
Re: __init dependencies
Quoted 3 lines · Randy.Dunlap
My experience with output of buildcheck is that it's verbose and has
lots of false positives.
I berated Keith over that a while back and he shot me down. umm...
Quoted 55 lines
Quoted 3 lines · Andrew Morton
gad,
reference_initgenerates so much stuff I wonder if it's worth using. Are all these for real?Apart from altinstructions, yes. Mainly because people have not been checking them.
Quoted 5 lines
perl
scripts/reference_init.pl
Finding objects, 1411 objects, ignoring 122 module(s) Finding conglomerates, ignoring 137 conglomerate(s) Scanning objects
Error:./arch/i386/kernel/apic.o.data refers to0000009cR_386_32.init.text
arch/i386/kernel/apic.c
void (*wait_timer_tick)(void) =wait_8254_wraparound;wait_8254_wraparoundis__init.wait_timer_tickshould be__initdata, which flows onto several other functions.Quoted 1 line
Error:
./arch/i386/kernel/cpu/mtrr/centaur.o.data refers to 00000008R_386_32.init.textThat is real, centaur_mtrr_ops.init =
centaur_mcr_init. Like a lot of this initialization code, we get away with the dangling reference because the code is only executed at boot.Quoted 1 line
Error:
./arch/i386/kernel/cpu/mtrr/centaur.o.eh_frame refers to000000dcR_386_32.init.textI don't see any .eh_frame references in 2.6.7-rc2 using gcc version 3.3.3 20040412 (Red Hat Linux 3.3.3-7). Where are they coming from?
Quoted 1 line
Error:
./arch/i386/kernel/cpu/mtrr/cyrix.o.data refers to 00000028R_386_32.init.textSame as centaur.
Quoted 1 line
Error:
./arch/i386/kernel/cpu/mtrr/generic.o.text refers to0000038fR_386_32.init.data
arch/i386/kernel/cpu/mtrr/generic.cgeneric_set_all()uses__intdatasmp_changes_mask.Quoted 1 line
Error:
./arch/i386/kernel/smpboot.o.altinstructions refers to 00000000R_386_32.init.textaltinstructions is a false positive, tweak reference_init.pl
--- reference_init.pl.orig 2004-06-01 20:30:27.000000000 +1000
+++ reference_init.pl 2004-06-01 20:31:01.000000000 +1000
@@ -93,6 +93,7 @@
$from !~ /\.stab$/ &&
$from !~ /\.rodata$/ &&
$from !~ /\.text\.lock$/ &&
+ $from !~ /\.altinstructions$/ &&
$from !~ /\.debug_/)) {
printf("Error: %s %s refers to %s\n", $object, $from, $line);
}
Quoted 2 lines
The rest of the warnings look real, apart from the strange
eh_frame.
So what you think are false positives may well not be.
Re: __init dependencies
In reply to Randy.DunlapQuoted 12 lines · Randy.Dunlap
Quoted 7 lines · Randy.Dunlap
Quoted 5 lines · Andrew Morton
Quoted 1 line · Geert Uytterhoeven
I guess it's about time for a tool to autodetect
__initdependencies?`make buildcheck' does this. Looks like nobody is using it.
John Cherry has been running 'make buildcheck' regularly, but apparently nobody has been looking.
Quoted 7 lines
Latest (2.6.9-rc4) is here:
http://developer.osdl.org/cherry/compile/2.6/linux-2.6.9-rc4.results/2.6.9-rc4.reference_init26.bzImage.txtMy experience with output of buildcheck is that it's verbose and has lots of false positives. (Yes, I have used it and generated patches from it.) First thing I do is delete all lines that match "data.*init" or "data.*exit". These are (usually -- famous word) OK.
They may only be OK because the code is never run more than once. Normal code that refers to data.*init and is run more than once is a bug just waiting to bite you.
Andrew - small fix for reference_init.pl, against 2.6.9-rc4.
------------------------------------------------------------
Treat .pci_fixup entries the same as .init code/data.
Signed off by: Keith Owens <[email protected]>
scripts/reference_init.pl +2 -0
@@ -93,6 +93,8 @@ foreach $object (sort(keys(%object))) { $from !~ /\.stab$/ && $from !~ /\.rodata$/ && $from !~ /\.text\.lock$/ && + $from !~ /\.pci_fixup_header$/ && + $from !~ /\.pci_fixup_final$/ && $from !~ /\.debug_/)) { printf("Error: %s %s refers to %s\n", $object, $from, $line); }
PATCH 1/1 __init dependencies: ignore __param
Quoted 19 lines · Keith Owens
They may only be OK because the code is never run more than once. Normal code that refers to data.*init and is run more than once is a bug just waiting to bite you.
Andrew - small fix for reference_init.pl, against 2.6.9-rc4.
------------------------------------------------------------
Treat .pci_fixup entries the same as .init code/data.
Signed off by: Keith Owens <[email protected]>
Index:
linux/scripts/reference_init.pl
===================================================================
scripts/reference_init.pl foreach $object (sort(keys(%object))) { · line 100
Quoted 8 lines
scripts/reference_init.pl +2
-0@@ -93,6 +93,8 @@ foreach $object (sort(keys(%object))) { $from !~ /\.stab$/ && $from !~ /\.rodata$/ && $from !~ /\.text\.lock$/ && + $from !~ /\.pci_fixup_header$/ && + $from !~ /\.pci_fixup_final$/ && $from !~ /\.debug_/)) { printf("Error: %s %s refers to %s\n", $object, $from, $line); }
Keith,
It looks like __param section references can also be safely ignored by 'reference_init.pl', since they are not discarded AFAIK. Or am I wrong about that one?
Patch attached -- applies on top of yours.
Signature · 1 line
~Randy
Ignore __param section references; they aren't discarded.
Error: ./drivers/mtd/devices/phram.o __param refers to 0000000000000010 R_X86_64_64 .init.text+0x0000000000000013
Error: ./drivers/scsi/dc395x.o __param refers to 0000000000000020 R_X86_64_64 .init.data+0x0000000000000064
Error: ./drivers/usb/gadget/ether.o __param refers to 0000000000000048 R_X86_64_64 .init.data+0x0000000000000020
diffstat:=
scripts/reference_init.pl | 1 + 1 files changed, 1 insertion(+)
scripts/reference_init.pl renamed from scripts/reference_init.pl~refer_param +1 -0
@@ -95,6 +95,7 @@ foreach $object (sort(keys(%object))) { $from !~ /\.text\.lock$/ && $from !~ /\.pci_fixup_header$/ && $from !~ /\.pci_fixup_final$/ && + $from !~ /\__param$/ && $from !~ /\.debug_/)) { printf("Error: %s %s refers to %s\n", $object, $from, $line); }