* [PATCH] find_isa_irq_pin can't be __init
@ 2004-10-10 22:57 Dave Jones
2004-10-11 11:33 ` __init dependencies (was: Re: [PATCH] find_isa_irq_pin can't be )__init Geert Uytterhoeven
0 siblings, 1 reply; 9+ messages in thread
From: Dave Jones @ 2004-10-10 22:57 UTC (permalink / raw)
To: torvalds, akpm; +Cc: linux-kernel
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.
Signed-off-by: Dave Jones <davej@redhat.com>
--- linux-2.6.8/arch/i386/kernel/io_apic.c~ 2004-10-10 18:54:27.490567168 -0400
+++ linux-2.6.8/arch/i386/kernel/io_apic.c 2004-10-10 18:54:44.660956872 -0400
@@ -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;
^ permalink raw reply [flat|nested] 9+ messages in thread* __init dependencies (was: Re: [PATCH] find_isa_irq_pin can't be )__init 2004-10-10 22:57 [PATCH] find_isa_irq_pin can't be __init Dave Jones @ 2004-10-11 11:33 ` Geert Uytterhoeven 2004-10-11 19:12 ` Andrew Morton 0 siblings, 1 reply; 9+ messages in thread From: Geert Uytterhoeven @ 2004-10-11 11:33 UTC (permalink / raw) To: Dave Jones; +Cc: Linus Torvalds, Andrew Morton, Linux Kernel Development On Sun, 10 Oct 2004, Dave Jones wrote: > 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 -- geert@linux-m68k.org 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: __init dependencies (was: Re: [PATCH] find_isa_irq_pin can't be )__init 2004-10-11 11:33 ` __init dependencies (was: Re: [PATCH] find_isa_irq_pin can't be )__init Geert Uytterhoeven @ 2004-10-11 19:12 ` Andrew Morton 2004-10-11 19:16 ` Dave Jones 2004-10-11 19:17 ` __init dependencies Randy.Dunlap 0 siblings, 2 replies; 9+ messages in thread From: Andrew Morton @ 2004-10-11 19:12 UTC (permalink / raw) To: Geert Uytterhoeven; +Cc: davej, torvalds, linux-kernel Geert Uytterhoeven <geert@linux-m68k.org> wrote: > > I guess it's about time for a tool to autodetect __init dependencies? `make buildcheck' does this. Looks like nobody is using it. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: __init dependencies (was: Re: [PATCH] find_isa_irq_pin can't be )__init 2004-10-11 19:12 ` Andrew Morton @ 2004-10-11 19:16 ` Dave Jones 2004-10-11 19:17 ` __init dependencies Randy.Dunlap 1 sibling, 0 replies; 9+ messages in thread From: Dave Jones @ 2004-10-11 19:16 UTC (permalink / raw) To: Andrew Morton; +Cc: Geert Uytterhoeven, torvalds, linux-kernel On Mon, Oct 11, 2004 at 12:12:25PM -0700, Andrew Morton wrote: > Geert Uytterhoeven <geert@linux-m68k.org> wrote: > > > > 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: __init dependencies 2004-10-11 19:12 ` Andrew Morton 2004-10-11 19:16 ` Dave Jones @ 2004-10-11 19:17 ` Randy.Dunlap 2004-10-12 4:04 ` Randy.Dunlap 1 sibling, 1 reply; 9+ messages in thread From: Randy.Dunlap @ 2004-10-11 19:17 UTC (permalink / raw) To: Andrew Morton; +Cc: Geert Uytterhoeven, davej, torvalds, linux-kernel Andrew Morton wrote: > Geert Uytterhoeven <geert@linux-m68k.org> wrote: > >>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.... -- ~Randy MOTD: Always include version info. (Again. Sometimes I think ln -s /usr/src/linux/.config .signature) ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: __init dependencies 2004-10-11 19:17 ` __init dependencies Randy.Dunlap @ 2004-10-12 4:04 ` Randy.Dunlap 2004-10-12 4:19 ` Andrew Morton 2004-10-12 6:06 ` Keith Owens 0 siblings, 2 replies; 9+ messages in thread From: Randy.Dunlap @ 2004-10-12 4:04 UTC (permalink / raw) To: Randy.Dunlap Cc: Andrew Morton, Geert Uytterhoeven, davej, torvalds, linux-kernel Randy.Dunlap wrote: > Andrew Morton wrote: > >> Geert Uytterhoeven <geert@linux-m68k.org> wrote: >> >>> 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.... 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. -- ~Randy ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: __init dependencies 2004-10-12 4:04 ` Randy.Dunlap @ 2004-10-12 4:19 ` Andrew Morton 2004-10-12 6:06 ` Keith Owens 1 sibling, 0 replies; 9+ messages in thread From: Andrew Morton @ 2004-10-12 4:19 UTC (permalink / raw) To: Randy.Dunlap; +Cc: rddunlap, geert, davej, torvalds, linux-kernel "Randy.Dunlap" <rddunlap@osdl.org> wrote: > > 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... > On Mon, 31 May 2004 23:52:14 -0700, > Andrew Morton <akpm@osdl.org> wrote: > > > >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. > > >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. > > >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. > > >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? > > >Error: ./arch/i386/kernel/cpu/mtrr/cyrix.o .data refers to 00000028 R_386_32 .init.text > > Same as centaur. > > >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. > > >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); > } > > The rest of the warnings look real, apart from the strange eh_frame. > So what you think are false positives may well not be. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: __init dependencies 2004-10-12 4:04 ` Randy.Dunlap 2004-10-12 4:19 ` Andrew Morton @ 2004-10-12 6:06 ` Keith Owens 2004-10-20 16:08 ` [PATCH] __init dependencies: ignore __param Randy.Dunlap 1 sibling, 1 reply; 9+ messages in thread From: Keith Owens @ 2004-10-12 6:06 UTC (permalink / raw) To: Randy.Dunlap Cc: Andrew Morton, Geert Uytterhoeven, davej, torvalds, linux-kernel On Mon, 11 Oct 2004 21:04:46 -0700, "Randy.Dunlap" <rddunlap@osdl.org> wrote: >Randy.Dunlap wrote: >> Andrew Morton wrote: >> >>> Geert Uytterhoeven <geert@linux-m68k.org> wrote: >>> >>>> 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. > >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 <kaos@ocs.com.au> Index: linux/scripts/reference_init.pl =================================================================== --- linux.orig/scripts/reference_init.pl Sat Aug 14 15:37:37 2004 +++ linux/scripts/reference_init.pl Tue Oct 12 15:59:39 2004 @@ -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); } ^ permalink raw reply [flat|nested] 9+ messages in thread
* [PATCH] __init dependencies: ignore __param 2004-10-12 6:06 ` Keith Owens @ 2004-10-20 16:08 ` Randy.Dunlap 0 siblings, 0 replies; 9+ messages in thread From: Randy.Dunlap @ 2004-10-20 16:08 UTC (permalink / raw) To: Keith Owens Cc: Andrew Morton, Geert Uytterhoeven, davej, torvalds, linux-kernel [-- Attachment #1: Type: text/plain, Size: 1264 bytes --] Keith Owens wrote: > > > 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 <kaos@ocs.com.au> > > Index: linux/scripts/reference_init.pl > =================================================================== > --- linux.orig/scripts/reference_init.pl Sat Aug 14 15:37:37 2004 > +++ linux/scripts/reference_init.pl Tue Oct 12 15:59:39 2004 > @@ -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. -- ~Randy [-- Attachment #2: refer_param.patch --] [-- Type: text/x-patch, Size: 1084 bytes --] 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 Signed-off-by: Randy Dunlap <rddunlap@osdl.org> diffstat:= scripts/reference_init.pl | 1 + 1 files changed, 1 insertion(+) diff -Naurp ./scripts/reference_init.pl~refer_param ./scripts/reference_init.pl --- ./scripts/reference_init.pl~refer_param 2004-10-20 08:39:44.976489696 -0700 +++ ./scripts/reference_init.pl 2004-10-20 08:45:26.217613160 -0700 @@ -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); } ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2004-10-20 16:29 UTC | newest] Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2004-10-10 22:57 [PATCH] find_isa_irq_pin can't be __init Dave Jones 2004-10-11 11:33 ` __init dependencies (was: Re: [PATCH] find_isa_irq_pin can't be )__init Geert Uytterhoeven 2004-10-11 19:12 ` Andrew Morton 2004-10-11 19:16 ` Dave Jones 2004-10-11 19:17 ` __init dependencies Randy.Dunlap 2004-10-12 4:04 ` Randy.Dunlap 2004-10-12 4:19 ` Andrew Morton 2004-10-12 6:06 ` Keith Owens 2004-10-20 16:08 ` [PATCH] __init dependencies: ignore __param Randy.Dunlap
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.
