Skip to contentSkip to conversation

find_isa_irq_pin can't be __init

PATCH In review Dave Jones 5 participants 9 messages Oct 10, 2004 – Oct 20, 2004

lore
Share & tools
lore

Dave Jones

author
#0 lore raw

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;
 
#1 lore raw

__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)
because disable_IO_APIC() wants to call find_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

#2 lore raw

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 __init dependencies?

`make buildcheck' does this. Looks like nobody is using it.

author
#3 lore raw

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 __init dependencies?

`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

#4 lore raw

Re: __init dependencies

In reply to Andrew Morton
Quoted 6 lines · Andrew Morton
Quoted 1 line · Geert Uytterhoeven

I guess it's about time for a tool to autodetect __init dependencies?

`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)
#5 lore raw

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 __init dependencies?

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
#6 lore raw

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_init generates 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 to 0000009c R_386_32 .init.text

arch/i386/kernel/apic.c
void (*wait_timer_tick)(void) = wait_8254_wraparound; wait_8254_wraparound is __init. wait_timer_tick should be __initdata, which flows onto several other functions.

Quoted 1 line

Error: ./arch/i386/kernel/cpu/mtrr/centaur.o .data refers to 00000008 R_386_32 .init.text

That 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 to 000000dc R_386_32 .init.text

I 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 00000028 R_386_32 .init.text

Same as centaur.

Quoted 1 line

Error: ./arch/i386/kernel/cpu/mtrr/generic.o .text refers to 0000038f R_386_32 .init.data

arch/i386/kernel/cpu/mtrr/generic.c generic_set_all() uses __intdata smp_changes_mask.

Quoted 1 line

Error: ./arch/i386/kernel/smpboot.o .altinstructions refers to 00000000 R_386_32 .init.text

altinstructions 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.

#7 lore raw

Re: __init dependencies

In reply to Randy.Dunlap
Quoted 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 __init dependencies?

`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.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.

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
Index: linux/scripts/reference_init.pl
===================================================================
@@ -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);
 		}
#8 lore raw

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
diff -Naurp ./scripts/reference_init.pl~refer_param ./scripts/reference_init.pl
@@ -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);
 		}