section mismatches

section mismatches

[Andrew Morton]

So I bravely did an i386 allmodconfig build on the current -mm lineup:

WARNING: vmlinux(.text+0xc010116f): Section mismatch: reference to .init.text:start_kernel (between 'is386' and 'check_x87')
WARNING: vmlinux(.text+0xc02f7af7): Section mismatch: reference to .init.text: (between 'rest_init' and 'alloc_node_mem_map')
WARNING: vmlinux(.text+0xc02fe08d): Section mismatch: reference to .init.text: (between 'iret_exc' and '_etext')
WARNING: vmlinux(.text+0xc02fe099): Section mismatch: reference to .init.text: (between 'iret_exc' and '_etext')
WARNING: vmlinux(.text+0xc02fe0a5): Section mismatch: reference to .init.text: (between 'iret_exc' and '_etext')
WARNING: vmlinux(.text+0xc02fe0b1): Section mismatch: reference to .init.text: (between 'iret_exc' and '_etext')
WARNING: vmlinux(.text+0xc02f7b83): Section mismatch: reference to .init.text:__alloc_bootmem_node (between 'alloc_node_mem_map' and 'zone_wait_table_init')
WARNING: vmlinux(.text+0xc02f7c53): Section mismatch: reference to .init.text:__alloc_bootmem_node (between 'zone_wait_table_init' and 'schedule')
WARNING: vmlinux(.text+0xc021dcc8): Section mismatch: reference to .init.text:__alloc_bootmem (between 'vgacon_startup' and 'vgacon_scrolldelta')
WARNING: vmlinux(.text+0xc02fe738): Section mismatch: reference to .init.text: (between 'iret_exc' and '_etext')
WARNING: vmlinux(.text+0xc02fe884): Section mismatch: reference to .init.text: (between 'iret_exc' and '_etext')
WARNING: vmlinux(.data+0xc0439099): Section mismatch: reference to .init.text:xen_start_kernel (between 'startup_xen' and 'boot_gdt_descr')

Could the people who write these bugs, please, like, fix them?

It's not trivial noise.  These things lead to kernel crashes.

Re: section mismatches

[Jeremy Fitzhardinge]

Andrew Morton wrote:
> WARNING: vmlinux(.text+0xc02fe884): Section mismatch: reference to .init.text: (between 'iret_exc' and '_etext')
> WARNING: vmlinux(.data+0xc0439099): Section mismatch: reference to .init.text:xen_start_kernel (between 'startup_xen' and 'boot_gdt_descr')
>   

This is safe, but I'll clean it up.  I'll also have a look at iret_exc,
some of which might be Xen-related.  Actually, iret_exc is in the fixup
section, but it gets used from several places, so it might be worth just
making it .text.

    J

Re: section mismatches

[Chris Wright]

* Jeremy Fitzhardinge (jeremy@goop.org) wrote:
> Andrew Morton wrote:
> > WARNING: vmlinux(.text+0xc02fe884): Section mismatch: reference to .init.text: (between 'iret_exc' and '_etext')
> > WARNING: vmlinux(.data+0xc0439099): Section mismatch: reference to .init.text:xen_start_kernel (between 'startup_xen' and 'boot_gdt_descr')
> >   
> 
> This is safe, but I'll clean it up.  I'll also have a look at iret_exc,
> some of which might be Xen-related.  Actually, iret_exc is in the fixup
> section, but it gets used from several places, so it might be worth just
> making it .text.

I tracked down a bunch of these a little while back.  It's not really
iret_exc, but since there is no _sfixup/_efixup markers iret_exc is the
closest symbol to pick on.  All the [iret_exc, _etext] warnings I found
were completely harmless from things that used, for example, mfn_to_pfn
in an __init function (which sucks in a fixup via __get_user).

Re: section mismatches

[Chris Wright]

* Chris Wright (chrisw@sous-sol.org) wrote:
> I tracked down a bunch of these a little while back.  It's not really
> iret_exc, but since there is no _sfixup/_efixup markers iret_exc is the
> closest symbol to pick on.  All the [iret_exc, _etext] warnings I found
> were completely harmless from things that used, for example, mfn_to_pfn
> in an __init function (which sucks in a fixup via __get_user).

Took a moment to check current -mm allmodconfig as Andrew did.

$ make ARCH=i386 O=obj-mod allmodconfig
$ make -j8 ARCH=i386 O=obj-mod > obj-mod/build.out 2>&1
$ objdump -dr -j.text obj-mod/vmlinux > obj-mod/objdump.out
$ grep iret_exc obj-mod/build.out | sed 's/.*(at offset 0x\(.*\)).*/\1/' | while read addr; do grep -B1 $addr obj-mod/objdump.out; done
c0306935:       e9 41 7e 19 00          jmp    c049e77b <romsignature+0x1f>
                        c0306936: R_386_PC32    .init.text
c0306941:       e9 83 7e 19 00          jmp    c049e7c9 <romchecksum+0x34>
                        c0306942: R_386_PC32    .init.text
c030694d:       e9 8e 85 19 00          jmp    c049eee0 <request_standard_resources+0x82>
                        c030694e: R_386_PC32    .init.text
c0306959:       e9 93 86 19 00          jmp    c049eff1 <request_standard_resources+0x193>
                        c030695a: R_386_PC32    .init.text
c0306fd4:       e9 bc c6 1a 00          jmp    c04b3695 <xenbus_probe_init+0x69>
                        c0306fd5: R_386_PC32    .init.text
c0307120:       e9 2c f3 1a 00          jmp    c04b6451 <pci_pcbios_init+0x33>
                        c0307121: R_386_PC32    .init.text

Each of these is indeed from __get_user called from an __init function.

- romsignature calls __get_user via probe_kernel_address
- romchecksum calls __get_user via probe_kernel_address
- request_standard_resources inlines probe_roms which
  twice calls __get_user via probe_kernel_address
- xenbus_probe_init calls __get_user via mfn_to_pfn
- pci_pcbios_init calls __get_user via probe_kernel_address

We could simply hush it up, by forcing that call to be out of line from
the __init function.  That's not really robust, since each callsite needs
attention (meaning new ones will sneak in over time).  Or fix the linker
script (and possibly modpost.c).

section mismatches

[Andrew Morton]

Mostly from Andi's tree:

WARNING: arch/i386/kernel/head.o(.note.Xen+0x68): Section mismatch: reference to .init.text:startup_xen
WARNING: vmlinux(.text+0xc0101183): Section mismatch: reference to .init.text:start_kernel (between 'is386' and 'check_x87')
WARNING: vmlinux(.text+0xc02fc63b): Section mismatch: reference to .init.text:kernel_init (between 'rest_init' and 'alloc_node_mem_map')
WARNING: vmlinux(.text+0xc0302e16): Section mismatch: reference to .init.text: (between 'iret_exc' and '_etext')
WARNING: vmlinux(.text+0xc0302e22): Section mismatch: reference to .init.text: (between 'iret_exc' and '_etext')
WARNING: vmlinux(.text+0xc0302e2e): Section mismatch: reference to .init.text: (between 'iret_exc' and '_etext')
WARNING: vmlinux(.text+0xc0302e3a): Section mismatch: reference to .init.text: (between 'iret_exc' and '_etext')
WARNING: vmlinux(.text+0xc02fc6c7): Section mismatch: reference to .init.text:__alloc_bootmem_node (between 'alloc_node_mem_map' and 'zone_wait_table_init')
WARNING: vmlinux(.text+0xc02fc797): Section mismatch: reference to .init.text:__alloc_bootmem_node (between 'zone_wait_table_init' and 'schedule')
WARNING: vmlinux(.text+0xc0222408): Section mismatch: reference to .init.text:__alloc_bootmem (between 'vgacon_startup' and 'vgacon_scrolldelta')
WARNING: vmlinux(.text+0xc03034c1): Section mismatch: reference to .init.text: (between 'iret_exc' and '_etext')
WARNING: vmlinux(.text+0xc030360d): Section mismatch: reference to .init.text: (between 'iret_exc' and '_etext')
WARNING: vmlinux(.notes+0x3d28): Section mismatch: reference to .init.text:startup_xen

Re: section mismatches

[Jeremy Fitzhardinge]

Andrew Morton wrote:
> Mostly from Andi's tree:
>
> WARNING: arch/i386/kernel/head.o(.note.Xen+0x68): Section mismatch: reference to .init.text:startup_xen
> WARNING: vmlinux(.notes+0x3d28): Section mismatch: reference to .init.text:startup_xen

Sam has the modpost patch to fix these two.

    J

Re: section mismatches

[Yinghai Lu]

please check patch in following too.

http://lkml.org/lkml/2007/5/25/76

YH

Re: section mismatches

[Sam Ravnborg]

On Wed, May 30, 2007 at 06:02:17PM -0700, Andrew Morton wrote:
> 
> Mostly from Andi's tree:
> 
> WARNING: arch/i386/kernel/head.o(.note.Xen+0x68): Section mismatch: reference to .init.text:startup_xen
> WARNING: vmlinux(.text+0xc0101183): Section mismatch: reference to .init.text:start_kernel (between 'is386' and 'check_x87')
> WARNING: vmlinux(.text+0xc02fc63b): Section mismatch: reference to .init.text:kernel_init (between 'rest_init' and 'alloc_node_mem_map')
> WARNING: vmlinux(.text+0xc0302e16): Section mismatch: reference to .init.text: (between 'iret_exc' and '_etext')
> WARNING: vmlinux(.text+0xc0302e22): Section mismatch: reference to .init.text: (between 'iret_exc' and '_etext')
> WARNING: vmlinux(.text+0xc0302e2e): Section mismatch: reference to .init.text: (between 'iret_exc' and '_etext')
> WARNING: vmlinux(.text+0xc0302e3a): Section mismatch: reference to .init.text: (between 'iret_exc' and '_etext')
> WARNING: vmlinux(.text+0xc02fc6c7): Section mismatch: reference to .init.text:__alloc_bootmem_node (between 'alloc_node_mem_map' and 'zone_wait_table_init')
> WARNING: vmlinux(.text+0xc02fc797): Section mismatch: reference to .init.text:__alloc_bootmem_node (between 'zone_wait_table_init' and 'schedule')
> WARNING: vmlinux(.text+0xc0222408): Section mismatch: reference to .init.text:__alloc_bootmem (between 'vgacon_startup' and 'vgacon_scrolldelta')
> WARNING: vmlinux(.text+0xc03034c1): Section mismatch: reference to .init.text: (between 'iret_exc' and '_etext')
> WARNING: vmlinux(.text+0xc030360d): Section mismatch: reference to .init.text: (between 'iret_exc' and '_etext')
> WARNING: vmlinux(.notes+0x3d28): Section mismatch: reference to .init.text:startup_xen

Some of the above happens during the MODPOST where we check modules.
The recently added trick to use __init_refok should have 'killed' at least
the one referring to rest_init. But running the check on the final vmlinux have thrown
the .text.init.refok into .text.
Will try to work out a fix for it.

> WARNING: vmlinux(.text+0xc0101183): Section mismatch: reference to .init.text:start_kernel (between 'is386' and 'check_x87')
I too a quick look at this one yesterday.
Code in head.S (for i386) are usually .init.text but in CONFIG_HOTPLUG_CPU it us .text.
But start_kernel() is __init.
Is it correct assumed that start_kernel() is never called in the HOTPLUG case since we
are dealign with CPU #2 and more?
If this is true I will introduce the .text.init.refok section.

	Sam

Re: section mismatches

[Sam Ravnborg]

On Wed, May 30, 2007 at 09:40:27PM -0700, Yinghai Lu wrote:
> please check patch in following too.
> 
> http://lkml.org/lkml/2007/5/25/76

Patch looks wrong (why remove all the markings).
In output posted by Andrew there is no references to mtrr - so I expect it
to be all clear in Andi's tree.

	Sam

Re: section mismatches

[Andrew Morton]

On Thu, 31 May 2007 06:50:33 +0200 Sam Ravnborg <sam@ravnborg.org> wrote:

> Is it correct assumed that start_kernel() is never called in the HOTPLUG case since we
> are dealign with CPU #2 and more?

start_kernel is called once, on the boot CPU, before the other CPUs are
brought up.

Re: section mismatches

[Sam Ravnborg]

On Wed, May 30, 2007 at 09:56:31PM -0700, Andrew Morton wrote:
> On Thu, 31 May 2007 06:50:33 +0200 Sam Ravnborg <sam@ravnborg.org> wrote:
> 
> > Is it correct assumed that start_kernel() is never called in the HOTPLUG case since we
> > are dealign with CPU #2 and more?
> 
> start_kernel is called once, on the boot CPU, before the other CPUs are
> brought up.
As expectyed - thanks.
I'm buried in section mismatch warnings at the moment but will come back to this
one a bit later. This needs a bit more careful thinking.

	Sam

Section Mismatches

[Felipe Balbi]

Hi Uwe,

I see that your commit 0db252452378aa7a9e001a13226e1cd1dc61453d removed 
the *_driver from the symbol whitelist when referencing init section 
(heh, it took a while), but could you explain what's the rationale 
behind that ?

Thanks a lot

-- 
balbi

DefectiveByDesign.org

Re: Section Mismatches

[Uwe Kleine-König]

Hi Felipe,

On Wed, Aug 04, 2010 at 02:11:56PM +0300, Felipe Balbi wrote:
> I see that your commit 0db252452378aa7a9e001a13226e1cd1dc61453d removed  
> the *_driver from the symbol whitelist when referencing init section  
> (heh, it took a while), but could you explain what's the rationale  
> behind that ?
The rational is that it's AFAIK wrong if a driver references a function
that lives in .init.text.

Do you think that's wrong?

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

Re: Section Mismatches

[Felipe Balbi]

On Wed, Aug 04, 2010 at 02:26:59PM +0200, ext Uwe Kleine-König wrote:
>Hi Felipe,
>
>On Wed, Aug 04, 2010 at 02:11:56PM +0300, Felipe Balbi wrote:
>> I see that your commit 0db252452378aa7a9e001a13226e1cd1dc61453d removed
>> the *_driver from the symbol whitelist when referencing init section
>> (heh, it took a while), but could you explain what's the rationale
>> behind that ?
>The rational is that it's AFAIK wrong if a driver references a function
>that lives in .init.text.

how about all the driver structures ? should they remove __init from 
probe() or stop saving the probe() function's pointer ?

That can be done for e.g. platform drivers, but for cpufreq_driver 
structures, I can't see a way to avoid a section mismatch (not without 
changing the cpufreq code a bit, at least). And, to me, that init has to 
live in the .init.text section as it's pretty much only called to 
initialize the frequency table for the cpu.

>Do you think that's wrong?

no, no. Not saying that. Just wondering what will happen with several 
drivers, will they change from _driver to _ops or try to stop saving 
probe() pointers into the driver structure.

-- 
balbi

DefectiveByDesign.org

Re: Section Mismatches

[Uwe Kleine-König]

Hello Felipe,

On Mon, Aug 09, 2010 at 09:08:31AM +0300, Felipe Balbi wrote:
> On Wed, Aug 04, 2010 at 02:26:59PM +0200, ext Uwe Kleine-König wrote:
>> Hi Felipe,
>>
>> On Wed, Aug 04, 2010 at 02:11:56PM +0300, Felipe Balbi wrote:
>>> I see that your commit 0db252452378aa7a9e001a13226e1cd1dc61453d removed
>>> the *_driver from the symbol whitelist when referencing init section
>>> (heh, it took a while), but could you explain what's the rationale
>>> behind that ?
>> The rational is that it's AFAIK wrong if a driver references a function
>> that lives in .init.text.
>
> how about all the driver structures ? should they remove __init from  
> probe() or stop saving the probe() function's pointer ?
>
> That can be done for e.g. platform drivers, but for cpufreq_driver  
> structures, I can't see a way to avoid a section mismatch (not without  
> changing the cpufreq code a bit, at least). And, to me, that init has to  
> live in the .init.text section as it's pretty much only called to  
> initialize the frequency table for the cpu.
I think they need handling similar handling like the usb gadget drivers.

See

	http://thread.gmane.org/gmane.linux.ports.ppc.embedded/37291/focus=34468

for the changes I suggested there.

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

Re: Section Mismatches

[Felipe Balbi]

Hi,

On Mon, Aug 09, 2010 at 08:49:36AM +0200, ext Uwe Kleine-König wrote:
>	http://thread.gmane.org/gmane.linux.ports.ppc.embedded/37291/focus=34468
>
>for the changes I suggested there.

I see, will look into it. Thanks

-- 
balbi

DefectiveByDesign.org