[PATCH] find_isa_irq_pin can't be __init

[PATCH] find_isa_irq_pin can't be __init

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

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;
 

__init dependencies (was: Re: [PATCH] find_isa_irq_pin can't be )__init

[Geert Uytterhoeven]

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

Re: __init dependencies (was: Re: [PATCH] find_isa_irq_pin can't be )__init

[Andrew Morton]

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.

Re: __init dependencies (was: Re: [PATCH] find_isa_irq_pin can't be )__init

[Dave Jones]

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

Re: __init dependencies

[Randy.Dunlap]

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)

Re: __init dependencies

[Randy.Dunlap]

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

Re: __init dependencies

[Andrew Morton]

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

Re: __init dependencies

[Keith Owens]

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);
 		}

[PATCH] __init dependencies: ignore __param

[Randy.Dunlap]

[-- 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);
 		}

Re: [PATCH] find_isa_irq_pin can't be __init

[Robert Hancock]

Confirmed, taking the __init off find_isa_irq_pin prevents the oops on 
reboot for me.


----- Original Message ----- 
From: "Dave Jones" <davej@redhat.com>
Newsgroups: fa.linux.kernel
To: <torvalds@osdl.org>; <akpm@osdl.org>
Cc: <linux-kernel@vger.kernel.org>
Sent: Sunday, October 10, 2004 4:58 PM
Subject: [PATCH] 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.
>
> 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;
>
> -
> 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/