2.5.59 vmlinux.lds.S change broke modules

2.5.59 vmlinux.lds.S change broke modules

[Mikael Pettersson]

Previously today I wrote:
 > 2.5.59 with CONFIG_PACKET=m oopes when af_packet.ko is insmodded:
 > 
 > Unable to handle kernel paging request at virtual address 2220c021
 >  printing eip:
 > c0124011
 > *pde = 00000000
 > Oops: 0000
 > CPU:    0
 > EIP:    0060:[<c0124011>]    Not tainted
 > EFLAGS: 00010097
 > EIP is at __find_symbol+0x3d/0x7c
 > eax: c020f70e   ebx: 00000536   ecx: 00000000   edx: c028b600
 > esi: 2220c021   edi: e8889558   ebp: e8889558   esp: e67c5ecc
 > ds: 007b   es: 007b   ss: 0068
 > Process insmod (pid: 482, threadinfo=e67c4000 task=e6c80ce0)
 > Stack: e8888f34 e8889a40 00000038 e8883f50 c0124960 e8889558 e67c5ef4 00000001 
 >        e8888f34 e8889374 e67c5f28 c0124b2a e8883f50 00000016 e8889374 e8889558 
 >        e8889a40 e8883f50 0000000c 00000017 e8889a40 00000000 0000007c c01253a4 
 > Call Trace:
 >  [<c0124960>] resolve_symbol+0x20/0x4c
 >  [<c0124b2a>] simplify_symbols+0x82/0xe4
 >  [<c01253a4>] load_module+0x5c4/0x7ec
 >  [<c012562b>] sys_init_module+0x5f/0x194
 >  [<c0108887>] syscall_call+0x7/0xb

This oops occurs for every module, not just af_packet.ko, at
resolve_symbol()'s first call to __find_symbol().

What happens is that __find_symbol() oopses because the kernel's
symbol table is in la-la land. (Note the bogus kernel adress
2220c021 it tried to dereference above.)

Reverting 2.5.59's patch to arch/i386/vmlinux.lds.S cured the
problem and modules now load correctly for me.

I don't know if this is a problem also for non-i386 archs.

/Mikael

Re: 2.5.59 vmlinux.lds.S change broke modules

[Brian Gerst]

Mikael Pettersson wrote:
> Previously today I wrote:
>  > 2.5.59 with CONFIG_PACKET=m oopes when af_packet.ko is insmodded:
>  > 
>  > Unable to handle kernel paging request at virtual address 2220c021
>  >  printing eip:
>  > c0124011
>  > *pde = 00000000
>  > Oops: 0000
>  > CPU:    0
>  > EIP:    0060:[<c0124011>]    Not tainted
>  > EFLAGS: 00010097
>  > EIP is at __find_symbol+0x3d/0x7c
>  > eax: c020f70e   ebx: 00000536   ecx: 00000000   edx: c028b600
>  > esi: 2220c021   edi: e8889558   ebp: e8889558   esp: e67c5ecc
>  > ds: 007b   es: 007b   ss: 0068
>  > Process insmod (pid: 482, threadinfo=e67c4000 task=e6c80ce0)
>  > Stack: e8888f34 e8889a40 00000038 e8883f50 c0124960 e8889558 e67c5ef4 00000001 
>  >        e8888f34 e8889374 e67c5f28 c0124b2a e8883f50 00000016 e8889374 e8889558 
>  >        e8889a40 e8883f50 0000000c 00000017 e8889a40 00000000 0000007c c01253a4 
>  > Call Trace:
>  >  [<c0124960>] resolve_symbol+0x20/0x4c
>  >  [<c0124b2a>] simplify_symbols+0x82/0xe4
>  >  [<c01253a4>] load_module+0x5c4/0x7ec
>  >  [<c012562b>] sys_init_module+0x5f/0x194
>  >  [<c0108887>] syscall_call+0x7/0xb
> 
> This oops occurs for every module, not just af_packet.ko, at
> resolve_symbol()'s first call to __find_symbol().
> 
> What happens is that __find_symbol() oopses because the kernel's
> symbol table is in la-la land. (Note the bogus kernel adress
> 2220c021 it tried to dereference above.)
> 
> Reverting 2.5.59's patch to arch/i386/vmlinux.lds.S cured the
> problem and modules now load correctly for me.
> 
> I don't know if this is a problem also for non-i386 archs.
> 
> /Mikael

What version of ld are you using?

--
				Brian Gerst

Re: 2.5.59 vmlinux.lds.S change broke modules

[Mikael Pettersson]

Brian Gerst writes:
 > Mikael Pettersson wrote:
 > > Previously today I wrote:
 > >  > 2.5.59 with CONFIG_PACKET=m oopes when af_packet.ko is insmodded:
 > >  > 
 > >  > Unable to handle kernel paging request at virtual address 2220c021
 > >  >  printing eip:
 > >  > c0124011
 > >  > *pde = 00000000
 > >  > Oops: 0000
 > >  > CPU:    0
 > >  > EIP:    0060:[<c0124011>]    Not tainted
 > >  > EFLAGS: 00010097
 > >  > EIP is at __find_symbol+0x3d/0x7c
 > >  > eax: c020f70e   ebx: 00000536   ecx: 00000000   edx: c028b600
 > >  > esi: 2220c021   edi: e8889558   ebp: e8889558   esp: e67c5ecc
 > >  > ds: 007b   es: 007b   ss: 0068
 > >  > Process insmod (pid: 482, threadinfo=e67c4000 task=e6c80ce0)
 > >  > Stack: e8888f34 e8889a40 00000038 e8883f50 c0124960 e8889558 e67c5ef4 00000001 
 > >  >        e8888f34 e8889374 e67c5f28 c0124b2a e8883f50 00000016 e8889374 e8889558 
 > >  >        e8889a40 e8883f50 0000000c 00000017 e8889a40 00000000 0000007c c01253a4 
 > >  > Call Trace:
 > >  >  [<c0124960>] resolve_symbol+0x20/0x4c
 > >  >  [<c0124b2a>] simplify_symbols+0x82/0xe4
 > >  >  [<c01253a4>] load_module+0x5c4/0x7ec
 > >  >  [<c012562b>] sys_init_module+0x5f/0x194
 > >  >  [<c0108887>] syscall_call+0x7/0xb
 > > 
 > > This oops occurs for every module, not just af_packet.ko, at
 > > resolve_symbol()'s first call to __find_symbol().
 > > 
 > > What happens is that __find_symbol() oopses because the kernel's
 > > symbol table is in la-la land. (Note the bogus kernel adress
 > > 2220c021 it tried to dereference above.)
 > > 
 > > Reverting 2.5.59's patch to arch/i386/vmlinux.lds.S cured the
 > > problem and modules now load correctly for me.
 > > 
 > > I don't know if this is a problem also for non-i386 archs.
 > > 
 > > /Mikael
 > 
 > What version of ld are you using?

2.13.90.0.2, as included in RH8.0.

/Mikael

Re: 2.5.59 vmlinux.lds.S change broke modules

[Mike Galbraith]

At 02:49 PM 1/17/2003 +0100, Mikael Pettersson wrote:
>Brian Gerst writes:
>  > Mikael Pettersson wrote:
>  > >
>  > > This oops occurs for every module, not just af_packet.ko, at
>  > > resolve_symbol()'s first call to __find_symbol().
>  > >
>  > > What happens is that __find_symbol() oopses because the kernel's
>  > > symbol table is in la-la land. (Note the bogus kernel adress
>  > > 2220c021 it tried to dereference above.)
>  > >
>  > > Reverting 2.5.59's patch to arch/i386/vmlinux.lds.S cured the
>  > > problem and modules now load correctly for me.
>  > >
>  > > I don't know if this is a problem also for non-i386 archs.
>  > >
>  > > /Mikael
>  >
>  > What version of ld are you using?
>
>2.13.90.0.2, as included in RH8.0.

It oopses with latest binutils too.

(binutils-2.13.2... _upgraded_ from 2.13.90.0.10;)

Re: 2.5.59 vmlinux.lds.S change broke modules

[Russell King]

On Fri, Jan 17, 2003 at 01:55:21PM +0100, Mikael Pettersson wrote:
> This oops occurs for every module, not just af_packet.ko, at
> resolve_symbol()'s first call to __find_symbol().
> 
> What happens is that __find_symbol() oopses because the kernel's
> symbol table is in la-la land. (Note the bogus kernel adress
> 2220c021 it tried to dereference above.)
> 
> Reverting 2.5.59's patch to arch/i386/vmlinux.lds.S cured the
> problem and modules now load correctly for me.
> 
> I don't know if this is a problem also for non-i386 archs.

Well:

        __start___ksymtab = .;                                          \
        __ksymtab         : AT(ADDR(__ksymtab) - LOAD_OFFSET) {         \
                *(__ksymtab)                                            \
        }                                                               \
        __stop___ksymtab = .;                                           \

breaks on some ARM binutils (from a couple of years ago.)  The most
reliable way we've found in with ARM binutils is to place the symbols
inside the section - this appears to work 100% every single time and
I've never had any reports of failure (whereas I did with the symbols
outside as above.)

On the topic of these changes, I'd prefer it if people didn't silently
run around making random stuff generic when there are subtle differences
between each architecture version without:

1. querying why things are different.
2. waiting a reasonable time for replies to why things are different.
3. copying such changes to the architecture maintainers for review
   in case steps 1 and 2 failed.

Unfortunately, it seems that the BK disease is growing and seems to
be killing the review process, as some people here predicted it
would. ;(

-- 
Russell King (rmk@arm.linux.org.uk)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html

Re: 2.5.59 vmlinux.lds.S change broke modules

[Eric W. Biederman]

Russell King <rmk@arm.linux.org.uk> writes:

> On Fri, Jan 17, 2003 at 01:55:21PM +0100, Mikael Pettersson wrote:
> > This oops occurs for every module, not just af_packet.ko, at
> > resolve_symbol()'s first call to __find_symbol().
> > 
> > What happens is that __find_symbol() oopses because the kernel's
> > symbol table is in la-la land. (Note the bogus kernel adress
> > 2220c021 it tried to dereference above.)
> > 
> > Reverting 2.5.59's patch to arch/i386/vmlinux.lds.S cured the
> > problem and modules now load correctly for me.
> > 
> > I don't know if this is a problem also for non-i386 archs.
> 
> Well:
> 
>         __start___ksymtab = .;                                          \
>         __ksymtab         : AT(ADDR(__ksymtab) - LOAD_OFFSET) {         \
>                 *(__ksymtab)                                            \
>         }                                                               \
>         __stop___ksymtab = .;                                           \
> 
> breaks on some ARM binutils (from a couple of years ago.)  The most
> reliable way we've found in with ARM binutils is to place the symbols
> inside the section - this appears to work 100% every single time and
> I've never had any reports of failure (whereas I did with the symbols
> outside as above.)

That has been roughly my experience on x86 as well with the exception
of bss sections.  For bss sections placing the symbols inside the section
itself has been deadly.

Eric

Re: 2.5.59 vmlinux.lds.S change broke modules

[Sam Ravnborg]

On Fri, Jan 17, 2003 at 09:13:14AM -0700, Eric W. Biederman wrote:
> That has been roughly my experience on x86 as well with the exception
> of bss sections.  For bss sections placing the symbols inside the section
> itself has been deadly.

Could you elaborate a bit more what you have seen?

	TIA,
		Sam

Re: 2.5.59 vmlinux.lds.S change broke modules

[Eric W. Biederman]

Sam Ravnborg <sam@ravnborg.org> writes:

> On Fri, Jan 17, 2003 at 09:13:14AM -0700, Eric W. Biederman wrote:
> > That has been roughly my experience on x86 as well with the exception
> > of bss sections.  For bss sections placing the symbols inside the section
> > itself has been deadly.
> 
> Could you elaborate a bit more what you have seen?

Sorry.  Placing symbols inside .bss sections (sections by any name
that are not allocated) has occasionally given them values not as
expected.  While at the same time placing the symbols around the .bss
sections has worked reliably for me.

Eric

Re: 2.5.59 vmlinux.lds.S change broke modules

[Kai Germaschewski]

On 17 Jan 2003, Eric W. Biederman wrote:

> > Well:
> > 
> >         __start___ksymtab = .;                                          \
> >         __ksymtab         : AT(ADDR(__ksymtab) - LOAD_OFFSET) {         \
> >                 *(__ksymtab)                                            \
> >         }                                                               \
> >         __stop___ksymtab = .;                                           \
> > 
> > breaks on some ARM binutils (from a couple of years ago.)  The most
> > reliable way we've found in with ARM binutils is to place the symbols
> > inside the section - this appears to work 100% every single time and
> > I've never had any reports of failure (whereas I did with the symbols
> > outside as above.)
> 
> That has been roughly my experience on x86 as well with the exception
> of bss sections.  For bss sections placing the symbols inside the section
> itself has been deadly.

Can both of you guys elaborate on what "break" means here, I'm trying to 
better understand what's going on. One thing is rather obvious, and that's 
what causing the current breakage with RH8 binutils:

If "." isn't properly aligned, __kstart___ksymtab will point to an address
which is before the actual start of the section, since that gets aligned 
to its requirements. Was that the ARM problem?

Now, what's different for __bss, i.e. what goes wrong there?

Related issue: The linker will actually automatically emit
__{start,stop}_SECTION symbols when SECTION is a C symbol (i.e.  
letters,numbers,_), so things should actually work without explicitly
defining those symbols. They do on i386 with my binutils, but I assume
there's some reason why we don't just rely on that?

--Kai

Re: 2.5.59 vmlinux.lds.S change broke modules

[Russell King]

On Fri, Jan 17, 2003 at 10:24:42AM -0600, Kai Germaschewski wrote:
> Can both of you guys elaborate on what "break" means here

You've already realised my problem I think - if you set the address
of a section explicitly, symbols around that section are set "not
as expected" unless they are inside the section itself.

> Related issue: The linker will actually automatically emit
> __{start,stop}_SECTION symbols when SECTION is a C symbol (i.e.  
> letters,numbers,_), so things should actually work without explicitly
> defining those symbols. They do on i386 with my binutils, but I assume
> there's some reason why we don't just rely on that?

It doesn't seem to be guaranteed.  For instance:

c03dddc8 ? __ksymtab_linkwatch_fire_event
c03dddd0 ? __ksymtab_profile_event_register
c03dddd0 A __start___gpl_ksymtab
c03dddd0 A __stop___ksymtab
c03dddd8 ? __ksymtab_profile_event_unregister
c03ddde0 ? __ksymtab_dequeue_signal
...
c03ddec8 ? __ksymtab_xfrm_ealg_get_byname
c03dded0 ? __kstrtab_sa1100fb_backlight_power
c03dded0 A __stop___gpl_ksymtab
c03ddeec ? __kstrtab_sa1100fb_lcd_power
c03ddf00 ? __kstrtab_sa1100_request_dma
...
c03e51e0 ? __kstrtab_register_gifconf
c03e51f4 ? __kstrtab_softnet_data
c03e5204 ? __kstrtab_linkwatch_fire_event
c03e6000 D init_thread_union
c03e8000 d runqueues
c03e8940 D tasklist_lock

Note that __start___ksymtab_strings and __stop___ksymtab_strings don't
exist, despite __ksymtab_strings being C symbol-like.

The only __start_ / __stop_ symbols which appear in System.map are those
which are explicitly defined:

rmk@raistlin:[linux-sa1100]:<1004> grep '__start_\|__stop_' System.map 
c021d050 ? __start___param
c021d050 ? __stop___param
c03da0b0 ? __start___ex_table
c03daa48 ? __stop___ex_table
c03daa58 A __start___ksymtab
c03dddd0 A __start___gpl_ksymtab
c03dddd0 A __stop___ksymtab
c03dded0 A __stop___gpl_ksymtab
rmk@raistlin:[rmk]:<1005> 

The only time that I've seen the linker automatically generate the __start_
and __stop_ symbols for a section is when the section isn't explicitly
placed by the linker file.  When sections aren't explicitly placed, more
things go wrong (the linker places them at some random address way outside
the kernel image) so this isn't an unacceptable solution either.

(This is as seen with ARM ld versions 2.10.1, 2.11.2, 2.12.1)

-- 
Russell King (rmk@arm.linux.org.uk)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html

Re: 2.5.59 vmlinux.lds.S change broke modules

[Sam Ravnborg]

On Fri, Jan 17, 2003 at 01:56:38PM +0000, Russell King wrote:
> Well:
> 
>         __start___ksymtab = .;                                          \
>         __ksymtab         : AT(ADDR(__ksymtab) - LOAD_OFFSET) {         \
>                 *(__ksymtab)                                            \
>         }                                                               \
>         __stop___ksymtab = .;                                           \
> 
> breaks on some ARM binutils (from a couple of years ago.)  The most
> reliable way we've found in with ARM binutils is to place the symbols
> inside the section - this appears to work 100% every single time and
> I've never had any reports of failure (whereas I did with the symbols
> outside as above.)

quote from 'info ld'
--------------
the address of the output section will be set to the current value of
the location counter aligned to the alignment requirements of the
output section.  The alignment requirement of the output section is the
strictest alignment of any input section contained within the output
section.
--------------

In other words, the value of __start___ksymtab may differ placed inside
or outside {}, if . is not aligned according to the rules above.
Was it binutils that faulted, or may ARM has been hit by this?

Usually vmlinux.lds.S files has a lot of un-commented . = ALIGN(N);
spread all over, that may have saved us several times in the past.

	Sam

Re: 2.5.59 vmlinux.lds.S change broke modules

[Kai Germaschewski]

On Fri, 17 Jan 2003, Mikael Pettersson wrote:

> What happens is that __find_symbol() oopses because the kernel's
> symbol table is in la-la land. (Note the bogus kernel adress
> 2220c021 it tried to dereference above.)
> 
> Reverting 2.5.59's patch to arch/i386/vmlinux.lds.S cured the
> problem and modules now load correctly for me.

That's interesting. It doesn't happen for me, but I'm using older 
binutils. The patch really only changes two things (except for ARM):
o whitespace
o It adds AT(ADDR(section) - 0)

Both of these should be NOPs, but apparently not. Could you try removing
the AT(...) from include/asm-generic/vmlinux.lds.h?

Also, what does
	objdump -h vmlinux
and
	grep __start_ System.map
say?

--Kai

Re: 2.5.59 vmlinux.lds.S change broke modules

[Kai Germaschewski]

On Fri, 17 Jan 2003, Mikael Pettersson wrote:

> This oops occurs for every module, not just af_packet.ko, at
> resolve_symbol()'s first call to __find_symbol().

Okay, the details I received so far seem to indicate that the appended 
patch will fix it, though I didn't get actual confirmation it does.

If you experience crashes when loading modules (and have RH 8 binutils), 
please give it a shot.

--Kai


-----------------------------------------------------------------------------
ChangeSet@1.947.1.2, 2003-01-16 16:29:31-06:00, kai@tp1.ruhr-uni-bochum.de
  kbuild: Fix __start_SECTION, __stop_SECTION
  
  In a discussion with Sam Ravnborg, the following problem became apparent:
  Most vmlinux.lds.S (but the ARM ones) used the following construct:
  
         __start___ksymtab = .;                                          
         __ksymtab         : AT(ADDR(__ksymtab) - LOAD_OFFSET) {         
                 *(__ksymtab)                                            
         }                                                               
         __stop___ksymtab = .;                                           
  
  However, the link will align the beginning of the section __ksymtab
  according to the requirements for the input sections. If '.' (current
  location counter) wasn't sufficiently aligned before, it's possible
  that __ksymtab actually starts at an address after the one
  __start___ksymtab points to, which will confuse the users of
  __start___ksymtab badly. The fix is to follow what the ARM Makefiles
  did for this case, ie
  
         __ksymtab : AT(ADDR(__ksymtab) - LOAD_OFFSET) {                 
                 __start___ksymtab = .;                                  
                 *(__ksymtab)                                            
                 __stop___ksymtab = .;                                   
         }                                                               

  ---------------------------------------------------------------------------

diff -Nru a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h
--- a/include/asm-generic/vmlinux.lds.h	Fri Jan 17 10:09:57 2003
+++ b/include/asm-generic/vmlinux.lds.h	Fri Jan 17 10:09:57 2003
@@ -13,18 +13,18 @@
 	}								\
 									\
 	/* Kernel symbol table: Normal symbols */			\
-	__start___ksymtab = .;						\
 	__ksymtab         : AT(ADDR(__ksymtab) - LOAD_OFFSET) {		\
+		__start___ksymtab = .;					\
 		*(__ksymtab)						\
+		__stop___ksymtab = .;					\
 	}								\
-	__stop___ksymtab = .;						\
 									\
 	/* Kernel symbol table: GPL-only symbols */			\
-	__start___gpl_ksymtab = .;					\
 	__gpl_ksymtab     : AT(ADDR(__gpl_ksymtab) - LOAD_OFFSET) {	\
+		__start___gpl_ksymtab = .;				\
 		*(__gpl_ksymtab)					\
+		__stop___gpl_ksymtab = .;				\
 	}								\
-	__stop___gpl_ksymtab = .;					\
 									\
 	/* Kernel symbol table: strings */				\
         __ksymtab_strings : AT(ADDR(__ksymtab_strings) - LOAD_OFFSET) {	\

Re: 2.5.59 vmlinux.lds.S change broke modules

[Christopher Faylor]

On Fri, Jan 17, 2003 at 06:11:01PM -0600, Kai Germaschewski wrote:
>On Fri, 17 Jan 2003, Mikael Pettersson wrote:
>
>> This oops occurs for every module, not just af_packet.ko, at
>> resolve_symbol()'s first call to __find_symbol().
>
>Okay, the details I received so far seem to indicate that the appended 
>patch will fix it, though I didn't get actual confirmation it does.
>
>If you experience crashes when loading modules (and have RH 8 binutils), 
>please give it a shot.

It isn't a scientific test since I also just added the 2.5.59-mm1
patches, but applying this patch seemed to fix my problems.  I'm sending
this from a kernel running 2.5.59 + mm1 + your patch, built with RH 8.0
binutils.

cgf

Re: 2.5.59 vmlinux.lds.S change broke modules

[J Sloan]

A confirmation from the peanut gallery -

2.5.59 oopses during boot, 2.5.59 plus the
vmlinux.lds.S  patch boots and runs fine -

Also Red Hat 8.0 -

Joe

Christopher Faylor wrote:

>On Fri, Jan 17, 2003 at 06:11:01PM -0600, Kai Germaschewski wrote:
>  
>
>>On Fri, 17 Jan 2003, Mikael Pettersson wrote:
>>
>>    
>>
>>>This oops occurs for every module, not just af_packet.ko, at
>>>resolve_symbol()'s first call to __find_symbol().
>>>      
>>>
>>Okay, the details I received so far seem to indicate that the appended 
>>patch will fix it, though I didn't get actual confirmation it does.
>>
>>If you experience crashes when loading modules (and have RH 8 binutils), 
>>please give it a shot.
>>    
>>
>
>It isn't a scientific test since I also just added the 2.5.59-mm1
>patches, but applying this patch seemed to fix my problems.  I'm sending
>this from a kernel running 2.5.59 + mm1 + your patch, built with RH 8.0
>binutils.
>
>cgf
>-
>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/
>
>  
>

Re: 2.5.59 vmlinux.lds.S change broke modules

[Mike Galbraith]

At 01:55 PM 1/17/2003 +0100, Mikael Pettersson wrote:

>Reverting 2.5.59's patch to arch/i386/vmlinux.lds.S cured the
>problem and modules now load correctly for me.

Hi,

Putting . = ALIGN(64) back in front of __start___ksymtab = . 
(vmlinux.lds.h) fixed it here.

         -Mike

Re: 2.5.59 vmlinux.lds.S change broke modules

[Sam Ravnborg]

On Sat, Jan 18, 2003 at 09:00:51AM +0100, Mike Galbraith wrote:
> At 01:55 PM 1/17/2003 +0100, Mikael Pettersson wrote:
> 
> >Reverting 2.5.59's patch to arch/i386/vmlinux.lds.S cured the
> >problem and modules now load correctly for me.
> 
> Hi,
> 
> Putting . = ALIGN(64) back in front of __start___ksymtab = . 
> (vmlinux.lds.h) fixed it here.

But that is just a way to hide the real problem.

With . = ALIGN(64);
you make sure that the linker does not do any alignment of .
when entering the section.
It is much better to let the linker do proper alignment, and not
to rely on a magic number in the .lds file.

Now consider if we decide to put in a new symbol with alignment 128 for
some reason. A little gcc magic is used to sepecy the alignment of
the symbol, but the resulting kernel oopses. Why?
Because the ALIGN() preceeding the section was not adjusted properly.
Only sane way is to move the labels inside the block, or at least let
them depend on the address of the section. The lables should not
be assigned the value of ., when we know the linker may adjust it.

The solution that Russell used for ARM is IMO the best way to do it.

The only issue remaining here is what the linker will do for an empty
section, as Eric points out. I have not investigated that.

	Sam

Re: 2.5.59 vmlinux.lds.S change broke modules

[Mike Galbraith]

At 10:23 AM 1/18/2003 +0100, Sam Ravnborg wrote:
>On Sat, Jan 18, 2003 at 09:00:51AM +0100, Mike Galbraith wrote:
> > At 01:55 PM 1/17/2003 +0100, Mikael Pettersson wrote:
> >
> > >Reverting 2.5.59's patch to arch/i386/vmlinux.lds.S cured the
> > >problem and modules now load correctly for me.
> >
> > Hi,
> >
> > Putting . = ALIGN(64) back in front of __start___ksymtab = .
> > (vmlinux.lds.h) fixed it here.
>
>But that is just a way to hide the real problem.

Yup.  I was only checking to see if that change was why it was 
croaking.  Kai's patch works a treat here.

         -Mike

Re: 2.5.59 vmlinux.lds.S change broke modules

[Mike Galbraith]

At 06:11 PM 1/17/2003 -0600, Kai Germaschewski wrote:
>On Fri, 17 Jan 2003, Mikael Pettersson wrote:
>
> > This oops occurs for every module, not just af_packet.ko, at
> > resolve_symbol()'s first call to __find_symbol().
>
>Okay, the details I received so far seem to indicate that the appended
>patch will fix it, though I didn't get actual confirmation it does.
>
>If you experience crashes when loading modules (and have RH 8 binutils),
>please give it a shot.

Works fine with 2.13.90.0.10 (not RH) and 2.13.2, both of which failed 
previously.

         thanks,

         -Mike

Re: 2.5.59 vmlinux.lds.S change broke modules

[Adam J. Richter]

	I believe I'm experiencing the same problem that Mikael Pettersson
reported, although the symptom is normally a hang with SMP, because
the bad pointer dereference in __find_symbol results in the fault
hanndler calling search_exception_tables, which calls search_module_extable,
which tries to grab the modlist_lock spinlock, but that lock was
already taken by resolve_symbol (which called __find_symbol in the first
place).

	Somone else on irc reported a similar problem when I asked.

	Thanks Mikael, for posting the kernel oops listing.  You
probably just saved me about 45 minutes of switching over to a
non-SMP kernel to check for that oops.

Adam J. Richter     __     ______________   575 Oroville Road
adam@yggdrasil.com     \ /                  Milpitas, California 95035
+1 408 309-6081         | g g d r a s i l   United States of America
                         "Free Software For The Rest Of Us."

Re: 2.5.59 vmlinux.lds.S change broke modules

[Mikael Pettersson]

On Fri, 17 Jan 2003 18:11:01 -0600 (CST), Kai Germaschewski wrote:
>Okay, the details I received so far seem to indicate that the appended 
>patch will fix it, though I didn't get actual confirmation it does.
>
>If you experience crashes when loading modules (and have RH 8 binutils), 
>please give it a shot.
...
>diff -Nru a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h
>--- a/include/asm-generic/vmlinux.lds.h	Fri Jan 17 10:09:57 2003
>+++ b/include/asm-generic/vmlinux.lds.h	Fri Jan 17 10:09:57 2003
>@@ -13,18 +13,18 @@
> 	}								\
> 									\
> 	/* Kernel symbol table: Normal symbols */			\
>-	__start___ksymtab = .;						\
> 	__ksymtab         : AT(ADDR(__ksymtab) - LOAD_OFFSET) {		\
>+		__start___ksymtab = .;					\
> 		*(__ksymtab)						\
>+		__stop___ksymtab = .;					\
> 	}								\
>-	__stop___ksymtab = .;						\
> 									\
> 	/* Kernel symbol table: GPL-only symbols */			\
>-	__start___gpl_ksymtab = .;					\
> 	__gpl_ksymtab     : AT(ADDR(__gpl_ksymtab) - LOAD_OFFSET) {	\
>+		__start___gpl_ksymtab = .;				\
> 		*(__gpl_ksymtab)					\
>+		__stop___gpl_ksymtab = .;				\
> 	}								\
>-	__stop___gpl_ksymtab = .;					\
> 									\
> 	/* Kernel symbol table: strings */				\
>         __ksymtab_strings : AT(ADDR(__ksymtab_strings) - LOAD_OFFSET) {	\
>

This patch fixed the module-loading problem for me. Thanks.

Note that the problem wasn't specific to RH8.0 binutils:
I've also seen it with binutils-2.10.91 from RH7.1.

/Mikael