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 -- To unsubscribe from this list: send the line "unsubscribe linux-parisc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
