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? 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? We'd use that in get_offset() so our layout and size calculations were correct, and use sh_size everywhere else. Cheers, Rusty. -- 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
