Messages in this thread | | | Date | Wed, 31 Dec 2008 00:02:41 +0100 | From | Helge Deller <> | Subject | Re: [PATCH] parisc: fix module loading failure of large kernel modules (take 2) |
| |
Rusty Russell wrote: > On Tuesday 30 December 2008 07:04:54 Helge Deller wrote: >> This is the second take of the patch series. >> Changes to previous version: >> - new CONFIG_HAVE_MODULE_SECTION_STUBS config option >> - put stub entries of a code section in front of the section >> >> ____________ >> The parisc port (esp. the 32bit kernel) currently lacks the ability to >> load large kernel modules like xfs or ipv6. This is a long outstanding >> bug and has already been reported a few times, e.g.: >> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=350482, >> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=401439, >> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=508489 >> >> The symptom is like this: >> # modprobe xfs >> FATAL: Error inserting xfs >> (/lib/modules/2.6.26-1-parisc/kernel/fs/xfs/xfs.ko): Invalid module >> format >> >> In dmesg: >> module xfs relocation of symbol xfs_btree_read_bufs is out of range >> (0x3ffefffe in 17 bits) >> >> The reason for the failure is, that the architecture only provides the >> R_PARISC_PCREL17F (for 32bit kernels) and R_PARISC_PCREL22F (for PA2.0 >> and 64bit kernels) relocations, which sometimes can't reach the target >> address of the stub entry if the kernel module is too large. Currently >> parisc (like other architectures) creates one big PLT section for all >> stubs at the beginning of the init and core sections. >> >> The following two patches changes the parisc module loader to put stubs >> for the code sections in front of each section, so that the distance to >> the stubs more easily fits into the available 17/22 bits. > > So now any one section has to pass 17 bits to break? How close are you with > the xfs module?
I did not tested it very much, but xfs is around 1.1M on disk, and ~750K when loaded. I think it breaked being 1/4 through the relocations.
> But it's kind of nasty, overloading sh_entsize further. Could we instead > do something like add a arch_module_section_size() weak fn which you can > overload?
Sure. I'll respin the patch.
> We'd use that in get_offset() so our layout and size calculations > were correct,
Yes, good.
> and use sh_size everywhere else.
BTW, although the comment states that arches can change section sizes in the module_frob_arch_sections() function: /* Allow arches to frob section contents and sizes. */ it will break horrible if you do so. What I found was, that if you change sh_size, at least the module references / dependency chain will break when running lsmod.
Helge
| |