ARM kernel module loader.
Ok, here's the problem I'm currently facing.
KAO's insmod used to do various fixups (trampolines of 8 bytes in length) before inserting modules into the kernel on ARM to make sure the PC24 branch relocations were able to reach the kernel binary image in memory. PC24 relocations have a maximum range of +/- 32MB, and the kernel may be (on current architectures) up to 256MB to 512MB away.
With Rusty's in-kernel module linker, there's a catch-22 situation here. The module linker has callouts to architecture code to ask for the size of various sections before allocating an area.
This is perfect in this situation, since all you need to do is calculate how many trampolines you'd need to reach the main kernel binary, and add that onto the core module size.
However, to know how many trampolines you'd need, you need to scan the relocations and symbols, counting the number of symbols that need trampolines. The problem here is that we haven't read any of the module into kernel space, so this information isn't available.
What is available though is the total number of relocations in the file, which could be massively larger than the number of trampolines required.
(For the time being, ARM has the code implemented that performs the basic linking, but obviously without the trampolines. Since this effectively means modules will never work, I've also made module_alloc always return NULL to force failure until we have a solution.)
Comments? Ideas? Solutions that don't require:
- rewriting the core module loading code
- introducing a vrealloc() function
- wasting lots of memory on trampoline entries that won't be used
Ideally, I'd like to be able to allocate a trampoline table for one module and re-use trampoline entries for many modules to minimise the cache impacts.
Signature · 2 lines
Russell King ([email protected]) The developer of ARM Linux http://www.arm.linux.org.uk/personal/aboutme.html
Quoted 7 lines · Russell King
Ok, here's the problem I'm currently facing.
KAO's insmod used to do various fixups (trampolines of 8 bytes in length) before inserting modules into the kernel on ARM to make sure the PC24 branch relocations were able to reach the kernel binary image in memory. PC24 relocations have a maximum range of +/- 32MB, and the kernel may be (on current architectures) up to 256MB to 512MB away.
Sounds exactly the same as the situation we face on ppc and ppc64.
Quoted 4 lines
With Rusty's in-kernel module linker, there's a catch-22 situation here. The module linker has callouts to architecture code to ask for the size of various sections before allocating an area.
Quoted 8 lines
This is perfect in this situation, since all you need to do is calculate how many trampolines you'd need to reach the main kernel binary, and add that onto the core module size.
However, to know how many trampolines you'd need, you need to scan the relocations and symbols, counting the number of symbols that need trampolines. The problem here is that we haven't read any of the module into kernel space, so this information isn't available.
The last statement is incorrect: look in load_module() in kernel/module.c. We read in the entire ELF file (i.e. copy it from userspace) at line 828 and call module_init_size and module_core_size further on (lines 946 and 951).
Have you looked at Rusty's patch to implement in-kernel module linking on PPC? It's on his web page on kernel.org. Unfortunately it appears to be for an older version of his modules code. I have updated it and I'll be pushing it to Linus shortly. The updated patch is below.
Quoted 3 lines
Ideally, I'd like to be able to allocate a trampoline table for one module and re-use trampoline entries for many modules to minimise the cache impacts.
Hmmm, interesting idea. :) It would only work if the modules landed close enough to each other in the kernel virtual space, of course. One idea that I have been considering is to steal a bit of the user address space immediately below KERNELBASE, say 16MB or so, and use that area for modules. That would mean we wouldn't need trampolines at all.
Regards,
Paul.
# This is a BitKeeper generated patch for the following project:
# Project Name: Linux kernel tree
# This patch format is intended for GNU patch command version 2.5 or higher. # This patch includes the following deltas:
# ChangeSet 1.907 -> 1.908
# include/asm-ppc/module.h 1.4 -> 1.5
# arch/ppc/kernel/Makefile 1.28 -> 1.29
# arch/ppc/kernel/misc.S 1.31 -> 1.32
# arch/ppc/mm/extable.c 1.3 -> 1.4
# (new) -> 1.1 arch/ppc/kernel/module.c
#
# The following is the BitKeeper ChangeSet Log
# --------------------------------------------
# 02/11/20 [email protected] 1.908
# PPC32: In-kernel module linker for PPC.
# --------------------------------------------
#
arch/ppc/kernel/Makefile +1 -1
@@ -25,7 +25,7 @@ cputable.o ppc_htab.o obj-$(CONFIG_6xx) += l2cr.o ppc6xx_idle.o obj-$(CONFIG_ALL_PPC) += ppc6xx_idle.o -obj-$(CONFIG_MODULES) += ppc_ksyms.o +obj-$(CONFIG_MODULES) += module.o ppc_ksyms.o obj-$(CONFIG_PCI) += pci.o ifneq ($(CONFIG_PPC_ISERIES),y) obj-$(CONFIG_PCI) += pci-dma.o
arch/ppc/kernel/misc.S +3 -3
@@ -1182,10 +1182,10 @@ .long sys_adjtimex .long sys_mprotect /* 125 */ .long sys_sigprocmask - .long sys_create_module + .long sys_ni_syscall /* old sys_create_module */ .long sys_init_module .long sys_delete_module - .long sys_get_kernel_syms /* 130 */ + .long sys_ni_syscall /* old sys_get_kernel_syms */ /* 130 */ .long sys_quotactl .long sys_getpgid .long sys_fchdir
@@ -1221,7 +1221,7 @@ .long sys_mremap .long sys_setresuid .long sys_getresuid /* 165 */ - .long sys_query_module + .long sys_ni_syscall /* old sys_query_module */ .long sys_poll .long sys_nfsservctl .long sys_setresgid
arch/ppc/kernel/module.c new file +260 -0
260 lines not on this page · raw message
arch/ppc/mm/extable.c +15 -10
@@ -70,24 +70,29 @@unsigned long search_exception_table (unsigned long addr) { -unsigned long ret; +unsigned long ret =0 ;#ifndef CONFIG_MODULES /* There is only the kernel to search. */ ret =search_one_table (__start___ex_table, __stop___ex_table-1 , addr); -if (ret)return ret;#else -/* The kernel is the last "module" -- no need to treat it special. */ -struct module *mp; -for (mp = module_list; mp !=NULL ; mp = mp->next) { -if (mp->ex_table_start ==NULL ) +unsigned long flags; +struct list_head *i; + +/* The kernel is the last "module" -- no need to treat it special. */ +spin_lock_irqsave (&modlist_lock, flags); +list_for_each (i, &extables) { +struct exception_table *ex + = list_entry(i, struct exception_table, list); +if (ex->num_entries ==0 )continue ; - ret =search_one_table (mp->ex_table_start, - mp->ex_table_end -1 , addr); + ret =search_one_table (ex->entry, + ex->entry + ex->num_entries -1 , addr);if (ret) -return ret; +break ; } +spin_unlock_irqrestore (&modlist_lock, flags);#endif -return 0 ; +return ret; }
include/asm-ppc/module.h +29 -8
@@ -1,12 +1,33 @@#ifndef _ASM_PPC_MODULE_H#define _ASM_PPC_MODULE_H -/* -* This file contains the PPC architecture specific module code. -*/ - -#define module_map (x) vmalloc(x) -#define module_unmap (x) vfree(x) -#define module_arch_init (x) (0) -#define arch_init_modules (x) do { } while (0) +/* Module stuff for PPC. (C) 2001 Rusty Russell */ + +/* Thanks to Paul M for explaining this. + +PPC can only do rel jumps += 32MB, and often the kernel and other +modules are furthur away than this. So, we jump to a table of +trampolines attached to the module (the Procedure Linkage Table) +whenever that happens. +*/ + +struct ppc_plt_entry +{ +/* 16 byte jump instruction sequence (4 instructions) */ +unsigned int jump[4 ]; +}; + +struct mod_arch_specific +{ +/* How much of the core is actually taken up with core (then +we know the rest is for the PLT */ +unsigned int core_plt_offset; + +/* Same for init */ +unsigned int init_plt_offset; +}; + +#define Elf_Shdr Elf32_Shdr +#define Elf_Sym Elf32_Sym +#define Elf_Ehdr Elf32_Ehdr#endif /* _ASM_PPC_MODULE_H */
In message <[email protected]> you write:
Quoted 7 lines
Ok, here's the problem I'm currently facing.
KAO's insmod used to do various fixups (trampolines of 8 bytes in length) before inserting modules into the kernel on ARM to make sure the PC24 branch relocations were able to reach the kernel binary image in memory. PC24 relocations have a maximum range of +/- 32MB, and the kernel may be (on current architectures) up to 256MB to 512MB away.
See PPC32, on my kernel.org page. Exactly the same issue.
Rusty.
--
Anyone who quotes me in their sig is an idiot. -- Rusty Russell.