LinuxLists.cc - BUG: sleeping function called from invalid context at kernel/fork.c:385

[permalink] [raw]

Subject: RE: BUG: sleeping function called from invalid context at kernel/fork.c:385

> > Saw this when running strace -f on a script on 2.6.21 on ia64:
> >
> > BUG: sleeping function called from invalid context at kernel/fork.c:385
> > in_atomic():1, irqs_disabled():0
... snip ...
> > I could reproduce it via 'strace -f sleep 1'
> >
>
> I'd say this is specific to ia64. Someone would have spotted it on
> x86 by now.

I tried the "strace -f sleep 1" on 2.6.22-rc2, and I didn't see this "BUG"
there. Can you try your other test cases on the latest kernel. If it has
already been fixed we can see about identifying the patch for possible backport
to 2.6.21.stable

-Tony

2007-05-30 03:31:00

by David Chinner

[permalink] [raw]

Subject: Re: BUG: sleeping function called from invalid context at kernel/fork.c:385

On Wed, May 23, 2007 at 10:44:16AM -0700, Luck, Tony wrote:
> > > Saw this when running strace -f on a script on 2.6.21 on ia64:
> > >
> > > BUG: sleeping function called from invalid context at kernel/fork.c:385
> > > in_atomic():1, irqs_disabled():0
> ... snip ...
> > > I could reproduce it via 'strace -f sleep 1'
> > >
> >
> > I'd say this is specific to ia64. Someone would have spotted it on
> > x86 by now.
>
> I tried the "strace -f sleep 1" on 2.6.22-rc2, and I didn't see this "BUG"
> there. Can you try your other test cases on the latest kernel. If it has
> already been fixed we can see about identifying the patch for possible backport
> to 2.6.21.stable

Sorry for taking so long to get back to this - I still see this in
2.6.22-rc2.

Cheers,

Dave.
--
Dave Chinner
Principal Engineer
SGI Australian Software Group

2007-05-30 04:45:12

by David Chinner

[permalink] [raw]

Subject: Re: BUG: sleeping function called from invalid context at kernel/fork.c:385

On Wed, May 30, 2007 at 01:30:41PM +1000, David Chinner wrote:
> On Wed, May 23, 2007 at 10:44:16AM -0700, Luck, Tony wrote:
> > > > Saw this when running strace -f on a script on 2.6.21 on ia64:
> > > >
> > > > BUG: sleeping function called from invalid context at kernel/fork.c:385
> > > > in_atomic():1, irqs_disabled():0
> > ... snip ...
> > > > I could reproduce it via 'strace -f sleep 1'
> > > >
> > >
> > > I'd say this is specific to ia64. Someone would have spotted it on
> > > x86 by now.
> >
> > I tried the "strace -f sleep 1" on 2.6.22-rc2, and I didn't see this "BUG"
> > there. Can you try your other test cases on the latest kernel. If it has
> > already been fixed we can see about identifying the patch for possible backport
> > to 2.6.21.stable
>
> Sorry for taking so long to get back to this - I still see this in
> 2.6.22-rc2.

Hmmm - I wonder if my tree is screwed up in some weird way. I'm seeing link
warnings as well:

AS .tmp_kallsyms2.o
LD vmlinux
SYSMAP System.map
SYSMAP .tmp_System.map
MODPOST vmlinux
WARNING: init/built-in.o - Section mismatch: reference to .init.data: from .sdata after 'root_mountflags' (at offset 0x38)
WARNING: init/built-in.o - Section mismatch: reference to .init.data:ino from .sdata after 'root_mountflags' (at offset 0x40)
WARNING: arch/ia64/kernel/built-in.o - Section mismatch: reference to .init.data:smp_boot_data from .sdata before 'acpi_irq_model' (at offset -0x0)
WARNING: arch/ia64/kernel/built-in.o - Section mismatch: reference to .init.data:rsvd_region from .sdata between 'ia64_sal' (at offset 0x118) and 'ia64_i_cache_stride_shift'
WARNING: arch/ia64/kernel/built-in.o - Section mismatch: reference to .init.data:smp_boot_data from .sdata between 'cpu.25267' (at offset0x2e8) and 'sal_state_for_booting_cpu'
WARNING: arch/ia64/mm/built-in.o - Section mismatch: reference to .init.data: from .sdata between 'hpage_shift' (at offset 0x50) and 'first_time.25897'
WARNING: arch/ia64/mm/built-in.o - Section mismatch: reference to .init.data: from .sdata between 'hpage_shift' (at offset 0x68) and 'first_time.25897'
WARNING: arch/ia64/mm/built-in.o - Section mismatch: reference to .init.data: from .sdata between 'hpage_shift' (at offset 0x70) and 'first_time.25897'
WARNING: arch/ia64/mm/built-in.o - Section mismatch: reference to .init.data: from .sdata between 'hpage_shift' (at offset 0x88) and 'first_time.25897'
WARNING: arch/ia64/mm/built-in.o - Section mismatch: reference to .init.data: from .sdata between 'hpage_shift' (at offset 0x90) and 'first_time.25897'
.....

There's more errors, but they are all section mismatch warnings.
I tried a make mrproper to see if that would fix but it didn't....

Cheers,

Dave.
--
Dave Chinner
Principal Engineer
SGI Australian Software Group

2007-05-30 20:11:32

[permalink] [raw]

Subject: RE: BUG: sleeping function called from invalid context at kernel/fork.c:385

> Hmmm - I wonder if my tree is screwed up in some weird way. I'm seeing link
> warnings as well:
>
> WARNING: init/built-in.o - Section mismatch: reference to .init.data: from .sdata after 'root_mountflags' (at offset 0x38)

I thought that I'd got the section mis-match warnings down to
just one (and that was in ACPI code, so I sent a patch to Len
for it).

Are you building from defconfig, or one of the standard ones? Changing
config options always has the possibility of unearthing new spots
where there are conflicts between __init, __cpuinit and __devinit.

But I've had other complaints that these Section mismatch warnings
are still showing up in kernels built from the "standard" config
files (arch/ia64/configs/*) ... which I'm not seeing. So I'm more
than a little confused about this.

These errors are unlikely to be related to the strace bug that
you've reported. I'll try to pound on this some more when I'm
back on the same continent as my test machines.

-Tony

2007-05-30 22:39:25

[permalink] [raw]

Subject: RE: BUG: sleeping function called from invalid context at kernel/fork.c:385

On Wed, 30 May 2007, Luck, Tony wrote:

> > WARNING: init/built-in.o - Section mismatch: reference to .init.data: from .sdata after 'root_mountflags' (at offset 0x38)
>
> I thought that I'd got the section mis-match warnings down to
> just one (and that was in ACPI code, so I sent a patch to Len
> for it).

Hmmm... My compilation of 2.6.21-rc2-mm1 just aborted with:
(used sn2_defconfig).

LD .tmp_vmlinux1
`.exit.text' referenced in section `.init.text' of drivers/built-in.o:
defined in discarded section `.exit.text' of drivers/built-in.o
make[2]: *** [.tmp_vmlinux1] Error 1
make[1]: *** [targz-pkg] Error 2
make: *** [targz-pkg] Error 2

2007-05-30 23:19:24

[permalink] [raw]

Subject: RE: BUG: sleeping function called from invalid context at kernel/fork.c:385

> `.exit.text' referenced in section `.init.text' of drivers/built-in.o:
> defined in discarded section `.exit.text' of drivers/built-in.o

This one is a fatal error ... the code is trying to call a function
that has been marked __exit in a driver that has been built-in, instead
of as a module. Since a builtin driver can never be unloaded, the kernel
has thrown away all the __exit routines (at link time).

The error message appears less than helpful in tracking down which
routine in which driver is the problem though.

-Tony

2007-05-30 23:31:46

[permalink] [raw]

Subject: RE: BUG: sleeping function called from invalid context at kernel/fork.c:385

On Wed, 30 May 2007, Luck, Tony wrote:

>
> > `.exit.text' referenced in section `.init.text' of drivers/built-in.o:
> > defined in discarded section `.exit.text' of drivers/built-in.o
>
>
> This one is a fatal error ... the code is trying to call a function
> that has been marked __exit in a driver that has been built-in, instead
> of as a module. Since a builtin driver can never be unloaded, the kernel
> has thrown away all the __exit routines (at link time).
>
> The error message appears less than helpful in tracking down which
> routine in which driver is the problem though.

Right. I have no idea where to look. The function has no name? Or is the
segment .exit.text referenced by namne in .init.text?

2007-05-30 23:36:25

by Randy Dunlap

[permalink] [raw]

Subject: Re: BUG: sleeping function called from invalid context at kernel/fork.c:385

On Wed, 30 May 2007 16:31:35 -0700 (PDT) Christoph Lameter wrote:

> On Wed, 30 May 2007, Luck, Tony wrote:
>
> >
> > > `.exit.text' referenced in section `.init.text' of drivers/built-in.o:
> > > defined in discarded section `.exit.text' of drivers/built-in.o
> >
> >
> > This one is a fatal error ... the code is trying to call a function
> > that has been marked __exit in a driver that has been built-in, instead
> > of as a module. Since a builtin driver can never be unloaded, the kernel
> > has thrown away all the __exit routines (at link time).
> >
> > The error message appears less than helpful in tracking down which
> > routine in which driver is the problem though.
>
> Right. I have no idea where to look. The function has no name? Or is the
> segment .exit.text referenced by namne in .init.text?

Maybe 'objdump drivers/built-in.o and then grep that output (file)
for /exit.text/ ...

---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***

2007-05-30 23:53:19

[permalink] [raw]

Subject: Re: BUG: sleeping function called from invalid context at kernel/fork.c:385

On Wed, 30 May 2007, Randy Dunlap wrote:

> > Right. I have no idea where to look. The function has no name? Or is the
> > segment .exit.text referenced by namne in .init.text?
>
> Maybe 'objdump drivers/built-in.o and then grep that output (file)
> for /exit.text/ ...

clameter@schroedinger:~/software/slub$ objdump -t drivers/built-in.o |grep "exit.text"
0000000000000000 l d .exit.text 0000000000000000 .exit.text
0000000000000000 l d *ABS* 0000000000000000 .rela.exit.text
0000000000000000 l d .IA_64.unwind_info.exit.text 0000000000000000 .IA_64.unwind_info.exit.text
0000000000000000 l d .IA_64.unwind.exit.text 0000000000000000 .IA_64.unwind.exit.text
0000000000000000 l d *ABS* 0000000000000000 .rela.IA_64.unwind.exit.text
0000000000000000 l F .exit.text 0000000000000050 pcie_portdrv_exit
0000000000000060 l F .exit.text 0000000000000040 aer_service_exit
00000000000000a0 l F .exit.text 0000000000000040 pci_hotplug_exit
00000000000000e0 l F .exit.text 00000000000000b0 pcied_cleanup
00000000000001a0 l F .exit.text 0000000000000160 mspec_exit
0000000000000300 l F .exit.text 0000000000000010 efi_rtc_exit
0000000000000320 l F .exit.text 0000000000000010 agp_exit
0000000000000340 l F .exit.text 00000000000000a0 sn_sal_module_exit
00000000000003e0 l F .exit.text 0000000000000040 firmware_class_exit
0000000000000420 l F .exit.text 0000000000000110 rd_cleanup
0000000000000540 l F .exit.text 00000000000001d0 loop_exit
0000000000000720 l F .exit.text 0000000000000040 tg3_cleanup
0000000000000760 l F .exit.text 0000000000000040 idedisk_exit
00000000000007a0 l F .exit.text 0000000000000040 ide_cdrom_exit
00000000000007e0 l F .exit.text 00000000000000a0 exit_scsi
0000000000000880 l F .exit.text 0000000000000080 spi_transport_exit
0000000000000900 l F .exit.text 00000000000000a0 fc_transport_exit
00000000000009a0 l F .exit.text 00000000000000e0 sas_transport_exit
0000000000000a80 l F .exit.text 0000000000000040 sas_class_exit
0000000000000ac0 l F .exit.text 0000000000000040 qla1280_exit
0000000000000b00 l F .exit.text 0000000000000140 qla2x00_module_exit
0000000000000c40 l F .exit.text 00000000000000a0 exit_sd
0000000000000ce0 l F .exit.text 0000000000000060 ata_exit
0000000000000d40 l F .exit.text 0000000000000040 vsc_sata_exit
0000000000000d80 l F .exit.text 00000000000000d0 fusion_exit
0000000000000e60 l F .exit.text 00000000000000e0 mptspi_exit
0000000000000f40 l F .exit.text 00000000000000d0 mptfc_exit
0000000000001020 l F .exit.text 00000000000000f0 mptsas_exit
0000000000001120 l F .exit.text 0000000000000060 cdrom_exit
0000000000001180 l F .exit.text 0000000000000080 input_exit
0000000000001200 l F .exit.text 0000000000000070 mousedev_exit
0000000000001280 l F .exit.text 0000000000000040 multipath_exit
00000000000012c0 l F .exit.text 0000000000000240 md_exit
0000000000001500 l F .exit.text 0000000000000090 dm_exit
00000000000015a0 l F .exit.text 0000000000000170 efivars_exit
0000000000001720 l F .exit.text 0000000000000010 hid_exit

2007-05-30 23:56:41

by Randy Dunlap

[permalink] [raw]

Subject: Re: BUG: sleeping function called from invalid context at kernel/fork.c:385

Christoph Lameter wrote:
> On Wed, 30 >
>>> Right. >>> segment >> Maybe >> for /exit.text/ ...

OK. I would write Then at each occurrence

> clameter@schroedin > 0000000000000000 l > 0000000000000000 l > 0000000000000000 l > 0000000000000000 l > 0000000000000000 l > 0000000000000000 l > 0000000000000060 l > 00000000000000a0 l > 00000000000000e0 l > 00000000000001a0 l > 0000000000000300 l > 0000000000000320 l > 0000000000000340 l > 00000000000003e0 l > 0000000000000420 l > 0000000000000540 l > 0000000000000720 l > 0000000000000760 l > 00000000000007a0 l > 00000000000007e0 l > 0000000000000880 l > 0000000000000900 l > 00000000000009a0 l > 0000000000000a80 l > 0000000000000ac0 l > 0000000000000b00 l > 0000000000000c40 l > 0000000000000ce0 l > 0000000000000d40 l > 0000000000000d80 l > 0000000000000e60 l > 0000000000000f40 l > 0000000000001020 l > 0000000000001120 l > 0000000000001180 l > 0000000000001200 l > 0000000000001280 l > 00000000000012c0 l > 0000000000001500 l > 00000000000015a0 l > 0000000000001720 l >

--
~Randy
*** Remember to May 2007, Randy Dunlap wrote:
I have no idea where to look. The function has no name? Or is the
.exit.text referenced by namne in .init.text?
'objdump drivers/built-in.o and then grep that output (file)
the file to disk and view it with an editor.
of /exit.text/, see if it's inside an __init function...
ger:~/software/slub$ objdump -t drivers/built-in.o |grep "exit.text"
d .exit.text 0000000000000000 .exit.text
d *ABS* 0000000000000000 .rela.exit.text
d .IA_64.unwind_info.exit.text 0000000000000000 .IA_64.unwind_info.exit.text
d .IA_64.unwind.exit.text 0000000000000000 .IA_64.unwind.exit.text
d *ABS* 0000000000000000 .rela.IA_64.unwind.exit.text
F .exit.text 0000000000000050 pcie_portdrv_exit
F .exit.text 0000000000000040 aer_service_exit
F .exit.text 0000000000000040 pci_hotplug_exit
F .exit.text 00000000000000b0 pcied_cleanup
F .exit.text 0000000000000160 mspec_exit
F .exit.text 0000000000000010 efi_rtc_exit
F .exit.text 0000000000000010 agp_exit
F .exit.text 00000000000000a0 sn_sal_module_exit
F .exit.text 0000000000000040 firmware_class_exit
F .exit.text 0000000000000110 rd_cleanup
F .exit.text 00000000000001d0 loop_exit
F .exit.text 0000000000000040 tg3_cleanup
F .exit.text 0000000000000040 idedisk_exit
F .exit.text 0000000000000040 ide_cdrom_exit
F .exit.text 00000000000000a0 exit_scsi
F .exit.text 0000000000000080 spi_transport_exit
F .exit.text 00000000000000a0 fc_transport_exit
F .exit.text 00000000000000e0 sas_transport_exit
F .exit.text 0000000000000040 sas_class_exit
F .exit.text 0000000000000040 qla1280_exit
F .exit.text 0000000000000140 qla2x00_module_exit
F .exit.text 00000000000000a0 exit_sd
F .exit.text 0000000000000060 ata_exit
F .exit.text 0000000000000040 vsc_sata_exit
F .exit.text 00000000000000d0 fusion_exit
F .exit.text 00000000000000e0 mptspi_exit
F .exit.text 00000000000000d0 mptfc_exit
F .exit.text 00000000000000f0 mptsas_exit
F .exit.text 0000000000000060 cdrom_exit
F .exit.text 0000000000000080 input_exit
F .exit.text 0000000000000070 mousedev_exit
F .exit.text 0000000000000040 multipath_exit
F .exit.text 0000000000000240 md_exit
F .exit.text 0000000000000090 dm_exit
F .exit.text 0000000000000170 efivars_exit
F .exit.text 0000000000000010 hid_exit
use Documentation/SubmitChecklist when testing your code ***

2007-05-30 23:57:00

by Fenghua Yu

[permalink] [raw]

Subject: RE: BUG: sleeping function called from invalid context at kernel/fork.c:385

> Saw this when running strace -f on a script on 2.6.21 on ia64
Run strace -f on 2.6.22-rc3 on Tiger4/Montecito. Couldn't reproduce
this issue. Kernel was built with both defconfig and tiger_defconfig.

Thanks.

-Fenghua

2007-05-31 00:10:11

[permalink] [raw]

Subject: Re: BUG: sleeping function called from invalid context at kernel/fork.c:385

On Wed, 30 May 2007, Randy Dunlap wrote:

> OK. I would write the file to disk and view it with an editor.
> Then at each occurrence of /exit.text/, see if it's inside an __init
> function...

Ahh okay. cscope will do that too.... But all have __exit.

2007-05-31 00:54:00

by David Chinner

[permalink] [raw]

Subject: Re: BUG: sleeping function called from invalid context at kernel/fork.c:385

On Wed, May 30, 2007 at 01:11:17PM -0700, Luck, Tony wrote:
> > Hmmm - I wonder if my tree is screwed up in some weird way. I'm seeing link
> > warnings as well:
> >
> > WARNING: init/built-in.o - Section mismatch: reference to .init.data: from .sdata after 'root_mountflags' (at offset 0x38)
>
> I thought that I'd got the section mis-match warnings down to
> just one (and that was in ACPI code, so I sent a patch to Len
> for it).
>
> Are you building from defconfig, or one of the standard ones?

sn2defconfig + kernel debug option plus xfs options.

> But I've had other complaints that these Section mismatch warnings
> are still showing up in kernels built from the "standard" config
> files (arch/ia64/configs/*) ... which I'm not seeing. So I'm more
> than a little confused about this.
>
> These errors are unlikely to be related to the strace bug that
> you've reported. I'll try to pound on this some more when I'm
> back on the same continent as my test machines.

Ok - no real hurry - they don't appear to be causing me any problems
except build noise....

Cheers,

Dave.
--
Dave Chinner
Principal Engineer
SGI Australian Software Group

2007-05-31 02:37:55

[permalink] [raw]

Subject: RE: BUG: sleeping function called from invalid context at kernel/fork.c:385

> Ahh okay. cscope will do that too.... But all have __exit.

The trick is that one of them *shouldn't* have __exit. With cscope
you'll have to use the "Find functions calling this function:"
mode to try and find the __init function that is calling an
__exit function.

-Tony

2007-05-31 03:19:31

[permalink] [raw]

Subject: RE: BUG: sleeping function called from invalid context at kernel/fork.c:385

On Wed, 30 May 2007, Luck, Tony wrote:

> > Ahh okay. cscope will do that too.... But all have __exit.
>
> The trick is that one of them *shouldn't* have __exit. With cscope
> you'll have to use the "Find functions calling this function:"
> mode to try and find the __init function that is calling an
> __exit function.

Urgh... Does it have to be that difficult?

2007-05-31 04:42:24

[permalink] [raw]

Subject: Re: BUG: sleeping function called from invalid context at kernel/fork.c:385

On Wed, May 30, 2007 at 04:31:35PM -0700, Christoph Lameter wrote:
> On Wed, 30 May 2007, Luck, Tony wrote:
>
> >
> > > `.exit.text' referenced in section `.init.text' of drivers/built-in.o:
> > > defined in discarded section `.exit.text' of drivers/built-in.o
> >
> >
> > This one is a fatal error ... the code is trying to call a function
> > that has been marked __exit in a driver that has been built-in, instead
> > of as a module. Since a builtin driver can never be unloaded, the kernel
> > has thrown away all the __exit routines (at link time).
> >
> > The error message appears less than helpful in tracking down which
> > routine in which driver is the problem though.
>
> Right. I have no idea where to look. The function has no name? Or is the
> segment .exit.text referenced by namne in .init.text?
Unfortunately modpost does not alows know how to resolve symbol names
from addresses. Lately it has been improves by adding support for
addends in ELF. But that is beyond my ELF knowledge atm so
I cannot improve it.

What you can do (apart from the cscope trick as Randy suggest) is
to run modpost manual on all .o files in drivers/

If the cross reference happens in a single .o file you will get
a hit there.
And if it is say in scsi then you will get a hit in scsi/built-in.o

Hope this helps.

Sam

2007-05-31 06:13:58

by Randy Dunlap

[permalink] [raw]

Subject: Re: BUG: sleeping function called from invalid context at kernel/fork.c:385

On Wed, 30 May 2007 17:09:56 -0700 (PDT) Christoph Lameter wrote:

> On Wed, 30 May 2007, Randy Dunlap wrote:
>
> > OK. I would write the file to disk and view it with an editor.
> > Then at each occurrence of /exit.text/, see if it's inside an __init
> > function...
>
> Ahh okay. cscope will do that too.... But all have __exit.

I did a cross-build, but I'm not having any luck finding the problem
either. FWIW, mine shows up as:

LD .tmp_vmlinux1
local symbol 0: discarded in section `.exit.text' from drivers/built-in.o
make[1]: [.tmp_vmlinux1] Error 1 (ignored)
KSYM .tmp_kallsyms1.S

---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***

2007-05-31 15:21:21

by Prarit Bhargava

[permalink] [raw]

Subject: Re: BUG: sleeping function called from invalid context at kernel/fork.c:385

--- linux/drivers/block/loop.c.orig 2007-05-31 11:15:21.000000000 -0400
+++ linux/drivers/block/loop.c 2007-05-31 11:11:05.000000000 -0400
@@ -1456,7 +1456,7 @@ static struct kobject *loop_probe(dev_t
return kobj;
}

-static void __exit loop_exit(void)
+static void loop_exit(void)
{
unsigned long range;
struct loop_device *lo, *next;

Attachments:

diff (346.00 B)

2007-05-31 19:53:39

[permalink] [raw]

Subject: Re: BUG: sleeping function called from invalid context at kernel/fork.c:385

On Thu, May 31, 2007 at 11:20:27AM -0400, Prarit Bhargava wrote:
>
>
> Christoph Lameter wrote:
> >On Wed, 30 May 2007, Luck, Tony wrote:
> >
> >
> >>>Ahh okay. cscope will do that too.... But all have __exit.
> >>>
> >>The trick is that one of them *shouldn't* have __exit. With cscope
> >>you'll have to use the "Find functions calling this function:"
> >>mode to try and find the __init function that is calling an
> >>__exit function.
> >>
> >
> >Urgh... Does it have to be that difficult?
> >-
> >
>
>
> Sometimes yes ... but in this case no.
>
> I flipped config options on and off until I tracked the problem down
> into the loopback driver, and then manually ran modpost on
> drivers/block/built-in.o to reveal:
>
> ....Nothing.
>
> Something is borken in modpost because I found a bug in the loopback
> code which is a _REAL_ bug.

In the initial version of the section mismatch check code
I ignored references to .exit.text from .init.text code.
Today I do not see why this should be allowed.
So unless an allmodconfig build for i386 + maybe a few more archs
does not show any significant regressions I will enable this check.

My initial i386 allmodconfig build pointed out a number of places
where this happened (I lost the warnings and are doing a rebuild now)A
.
One such place is microcode.c where we has

static int __init microcode_init (void)
{
...

if (IS_ERR(microcode_pdev)) {
microcode_dev_exit();
return PTR_ERR(microcode_pdev);
}

And:
static void __exit microcode_dev_exit (void)
{
misc_deregister(&microcode_dev);
}

I assume this is a real bug that we have not triggered
during testing becasue this is in an error-path.

The linker will not error out because .exit.text are discarded
at run-time at least for i386.

Sam

2007-05-31 20:03:56

[permalink] [raw]

Subject: Re: BUG: sleeping function called from invalid context at kernel/fork.c:385

On Thu, May 31, 2007 at 11:20:27AM -0400, Prarit Bhargava wrote:
>
> Something is borken in modpost because I found a bug in the loopback
> code which is a _REAL_ bug.

Here is the result for an i386 allmodconfig build:
WARNING: arch/i386/kernel/built-in.o(.init.text+0x3966): Section mismatch: reference to .exit.text: (between 'microcode_init' and 'parse_maxcpus')
WARNING: arch/i386/kernel/built-in.o(.init.text+0x3992): Section mismatch: reference to .exit.text: (between 'microcode_init' and 'parse_maxcpus')
Building modules, stage 2.
Kernel: arch/i386/boot/bzImage is ready (#4)
MODPOST 2100 modules
WARNING: drivers/acpi/asus_acpi.o(.init.text+0xb7): Section mismatch: reference to .exit.text: (after 'init_module')
WARNING: drivers/acpi/toshiba_acpi.o(.init.text+0x13a): Section mismatch: reference to .exit.text: (after 'init_module')
WARNING: drivers/block/loop.o(.init.text+0x6b): Section mismatch: reference to .exit.text: (after 'init_module')
WARNING: drivers/isdn/hardware/eicon/divadidd.o(.init.text+0xc4): Section mismatch: reference to .exit.text: (between 'init_module' and 'diddfunc_init')
WARNING: drivers/isdn/hardware/eicon/divas.o(.init.text+0xf4): Section mismatch: reference to .exit.text:divasfunc_exit (between 'init_module' and 'divasfunc_init')
WARNING: drivers/isdn/hardware/eicon/divas.o(.init.text+0x10d): Section mismatch: reference to .exit.text:divasfunc_exit (between 'init_module' and 'divasfunc_init')
WARNING: drivers/isdn/hardware/eicon/divas.o(.init.text+0x148): Section mismatch: reference to .exit.text:divasfunc_exit (between 'init_module' and 'divasfunc_init')
WARNING: drivers/kvm/kvm-intel.o(.init.text+0xbd): Section mismatch: reference to .exit.text: (between 'hardware_setup' and 'vmx_disabled_by_bios')
WARNING: drivers/net/hp100.o(.init.text+0x26a): Section mismatch: reference to .exit.text: (after 'init_module')

Sam

2007-05-31 20:08:44

[permalink] [raw]

Subject: [PATCH] net/hp100: fix section mismatch warning

Fix following section mismatch warning in hp100:

WARNING: drivers/net/hp100.o(.init.text+0x26a): Section mismatch: reference to .exit.text: (after 'init_module')

The warning says that we use a function marked __exit from a
function marked __init.
This is not good on architectures where we discard __exit section
for drivers that are built-in.

Signed-off-by: Sam Ravnborg <[email protected]>
---
Comple tested only.

Note: This warning does not appear with modpost in upstream kernel
but I would like to submit patches for the obvious bugs ASAP

Sam

diff --git a/drivers/net/hp100.c b/drivers/net/hp100.c
index 8118a67..8caa591 100644
--- a/drivers/net/hp100.c
+++ b/drivers/net/hp100.c
@@ -3005,7 +3005,7 @@ static int __init hp100_isa_init(void)
return cards > 0 ? 0 : -ENODEV;
}

-static void __exit hp100_isa_cleanup(void)
+static void hp100_isa_cleanup(void)
{
int i;

2007-05-31 20:16:34

[permalink] [raw]

Subject: [PATCH] kvm: fix section mismatch warning in kvm-intel.o

Fix following section mismatch warning in kvm-intel.o:
WARNING: o-i386/drivers/kvm/kvm-intel.o(.init.text+0xbd): Section mismatch: reference to .exit.text: (between 'hardware_setup' and 'vmx_disabled_by_bios')

The function free_kvm_area is used in the function alloc_kvm_area which
is marked __init.
The __exit area is discarded by some archs during link-time if a
module is built-in resulting in an oops.

Signed-off-by: Sam Ravnborg <[email protected]>
---
Note: This warning is only seen by my local copy of modpost
but the change will soon hit upstream.

Sam

diff --git a/drivers/kvm/vmx.c b/drivers/kvm/vmx.c
index e6e4d24..184238e 100644
--- a/drivers/kvm/vmx.c
+++ b/drivers/kvm/vmx.c
@@ -639,7 +639,7 @@ static void free_vmcs(struct vmcs *vmcs)
free_pages((unsigned long)vmcs, vmcs_descriptor.order);
}

-static __exit void free_kvm_area(void)
+static void free_kvm_area(void)
{
int cpu;

2007-05-31 20:23:57

[permalink] [raw]

Subject: [PATCH] acpi: fix section mismatch warning in asus_acpi.o

Fix following section mismatch warning in asus_acpi.o:

WARNING: drivers/acpi/asus_acpi.o(.init.text+0xb7): Section mismatch: reference to .exit.text: (after 'init_module')

The exit function is used in the init function during an error codition.
As __exit may be discarded during link-time / run-time this is no good.
Do not mark the exit function __exit.

Signed-off-by: Sam Ravnborg <[email protected]>
---
Note: This warning is only generated by a local copy of modpost
but it will soon hit upstream.

Sam

diff --git a/drivers/acpi/asus_acpi.c b/drivers/acpi/asus_acpi.c
index b770dea..6d7d415 100644
--- a/drivers/acpi/asus_acpi.c
+++ b/drivers/acpi/asus_acpi.c
@@ -1357,7 +1357,7 @@ static struct backlight_ops asus_backlight_data = {
.update_status = set_brightness_status,
};

-static void __exit asus_acpi_exit(void)
+static void asus_acpi_exit(void)
{
if (asus_backlight_device)
backlight_device_unregister(asus_backlight_device);

2007-05-31 20:28:18

[permalink] [raw]

Subject: Re: [PATCH] acpi: fix section mismatch warning in asus + toshiba

Fix following section mismatch warnings in acpi

WARNING: drivers/acpi/asus_acpi.o(.init.text+0xb7): Section mismatch: reference to .exit.text: (after 'init_module')
WARNING: o-i386/drivers/acpi/toshiba_acpi.o(.init.text+0x13a): Section mismatch: reference to .exit.text: (after 'init_module')

The exit function is used in the init function during an error codition.
As __exit may be discarded during link-time / run-time this is no good.
Do not mark the exit function __exit.

Signed-off-by: Sam Ravnborg <[email protected]>
---
Updated patch that covers both drivers.

Sam

diff --git a/drivers/acpi/asus_acpi.c b/drivers/acpi/asus_acpi.c
index b770dea..6d7d415 100644
--- a/drivers/acpi/asus_acpi.c
+++ b/drivers/acpi/asus_acpi.c
@@ -1357,7 +1357,7 @@ static struct backlight_ops asus_backlight_data = {
.update_status = set_brightness_status,
};

-static void __exit asus_acpi_exit(void)
+static void asus_acpi_exit(void)
{
if (asus_backlight_device)
backlight_device_unregister(asus_backlight_device);
diff --git a/drivers/acpi/toshiba_acpi.c b/drivers/acpi/toshiba_acpi.c
index 3906d47..1cfbecb 100644
--- a/drivers/acpi/toshiba_acpi.c
+++ b/drivers/acpi/toshiba_acpi.c
@@ -538,7 +538,7 @@ static struct backlight_ops toshiba_backlight_data = {
.update_status = set_lcd_status,
};

-static void __exit toshiba_acpi_exit(void)
+static void toshiba_acpi_exit(void)
{
if (toshiba_backlight_device)
backlight_device_unregister(toshiba_backlight_device);

2007-05-31 20:42:19

[permalink] [raw]

Subject: Re: BUG: sleeping function called from invalid context at kernel/fork.c:385

On Thu, 31 May 2007, Prarit Bhargava wrote:

> Christoph, this is one less beer I owe you :) :) :)

Finally the compile works. Thanks.

2007-05-31 20:45:19

[permalink] [raw]

Subject: [PATCH] isdn: fix section mismatch warnings

Fix the following section mismatch warnings:

WARNING: drivers/isdn/hardware/eicon/divadidd.o(.init.text+0xc4): Section mismatch: reference to .exit.text: (between 'init_module' and 'diddfunc_init')
WARNING: drivers/isdn/hardware/eicon/divas.o(.init.text+0xf4): Section mismatch: reference to .exit.text:divasfunc_exit (between 'init_module' and 'divasfunc_init')
WARNING: drivers/isdn/hardware/eicon/divas.o(.init.text+0x10d): Section mismatch: reference to .exit.text:divasfunc_exit (between 'init_module' and 'divasfunc_init')
WARNING: drivers/isdn/hardware/eicon/divas.o(.init.text+0x148): Section mismatch: reference to .exit.text:divasfunc_exit (between 'init_module' and 'divasfunc_init')

They all point to situation whare a function marked __init calls a function
marked __exit - but the __exit section may have been discarded.

Signed-off-by: Sam Ravnborg <[email protected]>
---
Note: This warning is generated by a modified copy of modpost in my
tree. It will soon hit upstearm.

Sam

diff --git a/drivers/isdn/hardware/eicon/diva_didd.c b/drivers/isdn/hardware/eicon/diva_didd.c
index 14298b8..d755d90 100644
--- a/drivers/isdn/hardware/eicon/diva_didd.c
+++ b/drivers/isdn/hardware/eicon/diva_didd.c
@@ -99,7 +99,7 @@ static int DIVA_INIT_FUNCTION create_proc(void)
return (0);
}

-static void DIVA_EXIT_FUNCTION remove_proc(void)
+static void remove_proc(void)
{
remove_proc_entry(DRIVERLNAME, proc_net_eicon);
remove_proc_entry("net/eicon", NULL);
diff --git a/drivers/isdn/hardware/eicon/divasfunc.c b/drivers/isdn/hardware/eicon/divasfunc.c
index df61e51..46fc21a 100644
--- a/drivers/isdn/hardware/eicon/divasfunc.c
+++ b/drivers/isdn/hardware/eicon/divasfunc.c
@@ -231,7 +231,7 @@ int DIVA_INIT_FUNCTION divasfunc_init(int dbgmask)
/*
* exit
*/
-void DIVA_EXIT_FUNCTION divasfunc_exit(void)
+void divasfunc_exit(void)
{
divasa_xdi_driver_unload();
disconnect_didd();

2007-05-31 20:50:31

[permalink] [raw]

Subject: [PATCH] microcode: fix section mismatch warning

Fix the following section mismatch warnings in microcode.c:
WARNING: arch/i386/kernel/built-in.o(.init.text+0x3966): Section mismatch: reference to .exit.text: (between 'microcode_init' and 'parse_maxcpus')
WARNING: arch/i386/kernel/built-in.o(.init.text+0x3992): Section mismatch: reference to .exit.text: (between 'microcode_init' and 'parse_maxcpus')

The warning are caused by a function marked __init that
calls a function marked __exit.
Functions marked __exit may be discarded either during link or run-time
and thus the reference is not good.

Signed-off-by: Sam Ravnborg <[email protected]>
---
diff --git a/arch/i386/kernel/microcode.c b/arch/i386/kernel/microcode.c
index 83f825f..d865d04 100644
--- a/arch/i386/kernel/microcode.c
+++ b/arch/i386/kernel/microcode.c
@@ -478,7 +478,7 @@ static int __init microcode_dev_init (void)
return 0;
}

-static void __exit microcode_dev_exit (void)
+static void microcode_dev_exit (void)
{
misc_deregister(&microcode_dev);
}

2007-06-01 03:18:52

[permalink] [raw]

Subject: RE: BUG: sleeping function called from invalid context at kernel/fork.c:385

> Tony, the ia64 section mismatch "whack-a-mole" is far from over :(

Can you post the .config file that you are using when you see all those
warnings ... I'll start bopping them on their cute little heads.

-Tony

2007-06-01 03:32:08

by Prarit Bhargava

[permalink] [raw]

Subject: Re: BUG: sleeping function called from invalid context at kernel/fork.c:385

Luck, Tony wrote:
>> Tony, the ia64 section mismatch "whack-a-mole" is far from over :(
>>
>
> Can you post the .config file that you are using when you see all those
> warnings ... I'll start bopping them on their cute little heads.
>
>

Hi Tony,

I used the sn2_defconfig in the tree :)

P.

> -Tony
>

2007-06-01 04:06:12

[permalink] [raw]

Subject: Re: BUG: sleeping function called from invalid context at kernel/fork.c:385

On Thu, 31 May 2007, Prarit Bhargava wrote:

> I used the sn2_defconfig in the tree :)

That is a static kernel build. Ideal for that kind of bug.

2007-06-01 04:16:34

[permalink] [raw]

Subject: Re: BUG: sleeping function called from invalid context at kernel/fork.c:385

On Thu, May 31, 2007 at 09:05:54PM -0700, Christoph Lameter wrote:
> On Thu, 31 May 2007, Prarit Bhargava wrote:
>
> > I used the sn2_defconfig in the tree :)
>
> That is a static kernel build. Ideal for that kind of bug.
Quite the opposite.
If modpost cannot resolve symbols you are jsut told what
top-level file it is in.
A allmodconfig should be more useful and give you warnings in all normal
cases.

Let me know if I shall look over some of the warnings.

Sam

2007-06-01 04:45:41

[permalink] [raw]

Subject: Re: BUG: sleeping function called from invalid context at kernel/fork.c:385

On Fri, 1 Jun 2007, Sam Ravnborg wrote:

> On Thu, May 31, 2007 at 09:05:54PM -0700, Christoph Lameter wrote:
> > On Thu, 31 May 2007, Prarit Bhargava wrote:
> >
> > > I used the sn2_defconfig in the tree :)
> >
> > That is a static kernel build. Ideal for that kind of bug.
> Quite the opposite.

I thought that a static kernel build would throw out the __exit sections?
So it should trigger the bug?

2007-06-01 06:41:39

[permalink] [raw]

Subject: Re: BUG: sleeping function called from invalid context at kernel/fork.c:385

On Thu, May 31, 2007 at 09:45:31PM -0700, Christoph Lameter wrote:
> On Fri, 1 Jun 2007, Sam Ravnborg wrote:
>
> > On Thu, May 31, 2007 at 09:05:54PM -0700, Christoph Lameter wrote:
> > > On Thu, 31 May 2007, Prarit Bhargava wrote:
> > >
> > > > I used the sn2_defconfig in the tree :)
> > >
> > > That is a static kernel build. Ideal for that kind of bug.
> > Quite the opposite.
>
> I thought that a static kernel build would throw out the __exit sections?
> So it should trigger the bug?
Correct. But the other section mismatch warnings that Prarit
posted was not related to .exit.text (IIRC).

Anyway I will try to do a ia64 build tonight to take a short look at it.
If there is something general then I will fix it in modpost.

Sam

2007-06-01 08:00:46

[permalink] [raw]

Subject: RE: BUG: sleeping function called from invalid context at kernel/fork.c:385

> I used the sn2_defconfig in the tree :)

So there is something odd happening. Russ complained that he
was still seeing several errors from the sn2_defconfig build
too when I posted the "last fix" to Len. But I don't see them
when I build.

-Tony

2007-06-01 10:30:46

by Prarit Bhargava

[permalink] [raw]

Subject: Re: BUG: sleeping function called from invalid context at kernel/fork.c:385

Luck, Tony wrote:
>> I used the sn2_defconfig in the tree :)
>>
>
> So there is something odd happening. Russ complained that he
> was still seeing several errors from the sn2_defconfig build
> too when I posted the "last fix" to Len. But I don't see them
> when I build.
>
>

Adding Vivek.

I've solved quite a few of the section mismatch errors as well. I'll
take a look to see what the problem is.

Tony, what system are you using to compile on, OS, etc?

P.

> -Tony
>

2007-06-01 10:37:26