linux/kernel/module.c, branch v3.11

Merge tag 'modules-next-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rusty/linux

2013-07-10T21:51:41Z

Pull module updates from Rusty Russell: "Nothing interesting. Except the most embarrassing bugfix ever. But let's ignore that" * tag 'modules-next-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rusty/linux: module: cleanup call chain. module: do percpu allocation after uniqueness check. No, really! modules: don't fail to load on unknown parameters. ABI: Clarify when /sys/module/MODULENAME is created There is no /sys/parameters module: don't modify argument of module_kallsyms_lookup_name()

module: cleanup call chain.

2013-07-03T00:45:10Z

Fold alloc_module_percpu into percpu_modalloc(). Signed-off-by: Rusty Russell

module: do percpu allocation after uniqueness check. No, really!

2013-07-03T00:45:09Z

v3.8-rc1-5-g1fb9341 was supposed to stop parallel kvm loads exhausting percpu memory on large machines: Now we have a new state MODULE_STATE_UNFORMED, we can insert the module into the list (and thus guarantee its uniqueness) before we allocate the per-cpu region. In my defence, it didn't actually say the patch did this. Just that we "can". This patch actually *does* it. Signed-off-by: Rusty Russell Tested-by: Jim Hull Cc: stable@kernel.org # 3.8

modules: don't fail to load on unknown parameters.

2013-07-02T06:08:21Z

Although parameters are supposed to be part of the kernel API, experimental parameters are often removed. In addition, downgrading a kernel might cause previously-working modules to fail to load. On balance, it's probably better to warn, and load the module anyway. This may let through a typo, but at least the logs will show it. Reported-by: Andy Lutomirski Signed-off-by: Rusty Russell

module: don't modify argument of module_kallsyms_lookup_name()

2013-07-02T06:08:18Z

If we pass a pointer to a const string in the form "module:symbol" module_kallsyms_lookup_name() will try to split the string at the colon, i.e., will try to modify r/o data. That will, in fact, fail on a kernel with enabled CONFIG_DEBUG_RODATA. Avoid modifying the passed string in module_kallsyms_lookup_name(), modify find_module_all() instead to pass it the module name length. Signed-off-by: Mathias Krause Signed-off-by: Rusty Russell

kmemleak: No need for scanning specific module sections

2013-05-17T08:53:36Z

As kmemleak now scans all module sections that are allocated, writable and non executable, there's no need to scan individual sections that might reference data. Signed-off-by: Steven Rostedt Signed-off-by: Catalin Marinas Acked-by: Rusty Russell

kmemleak: Scan all allocated, writeable and not executable module sections

2013-05-17T08:53:07Z

Instead of just picking data sections by name (names that start with .data, .bss or .ref.data), use the section flags and scan all sections that are allocated, writable and not executable. Which should cover all sections of a module that might reference data. Signed-off-by: Steven Rostedt [catalin.marinas@arm.com: removed unused 'name' variable] [catalin.marinas@arm.com: collapsed 'if' blocks] Signed-off-by: Catalin Marinas Acked-by: Rusty Russell

module: don't unlink the module until we've removed all exposure.

2013-04-17T03:53:02Z

Otherwise we get a race between unload and reload of the same module: the new module doesn't see the old one in the list, but then fails because it can't register over the still-extant entries in sysfs: [ 103.981925] ------------[ cut here ]------------ [ 103.986902] WARNING: at fs/sysfs/dir.c:536 sysfs_add_one+0xab/0xd0() [ 103.993606] Hardware name: CrownBay Platform [ 103.998075] sysfs: cannot create duplicate filename '/module/pch_gbe' [ 104.004784] Modules linked in: pch_gbe(+) [last unloaded: pch_gbe] [ 104.011362] Pid: 3021, comm: modprobe Tainted: G W 3.9.0-rc5+ #5 [ 104.018662] Call Trace: [ 104.021286] [] warn_slowpath_common+0x6d/0xa0 [ 104.026933] [] ? sysfs_add_one+0xab/0xd0 [ 104.031986] [] ? sysfs_add_one+0xab/0xd0 [ 104.037000] [] warn_slowpath_fmt+0x2e/0x30 [ 104.042188] [] sysfs_add_one+0xab/0xd0 [ 104.046982] [] create_dir+0x5e/0xa0 [ 104.051633] [] sysfs_create_dir+0x78/0xd0 [ 104.056774] [] kobject_add_internal+0x83/0x1f0 [ 104.062351] [] ? kvasprintf+0x46/0x60 [ 104.067231] [] kobject_add_varg+0x2d/0x50 [ 104.072450] [] kobject_init_and_add+0x27/0x30 [ 104.078075] [] mod_sysfs_setup+0x80/0x540 [ 104.083207] [] ? module_bug_finalize+0x51/0xc0 [ 104.088720] [] load_module+0x1429/0x18b0 We can teardown sysfs first, then to be sure, put the state in MODULE_STATE_UNFORMED so it's ignored while we deconstruct it. Reported-by: Veaceslav Falico Tested-by: Veaceslav Falico Signed-off-by: Rusty Russell

module: fix symbol versioning with symbol prefixes

2013-03-20T00:57:26Z

Fix symbol versioning on architectures with symbol prefixes. Although the build was free from warnings the actual modules still wouldn't load as the ____versions table contained unprefixed symbol names, which were being compared against the prefixed symbol names when checking the symbol versions. This is fixed by modifying modpost to add the symbol prefix to the ____versions table it outputs (Modules.symvers still contains unprefixed symbol names). The check_modstruct_version() function is also fixed as it checks the version of the unprefixed "module_layout" symbol which would no longer work. Signed-off-by: James Hogan Cc: Michal Marek Cc: Sam Ravnborg Cc: Greg Kroah-Hartman Cc: Jonathan Kliegman Signed-off-by: Rusty Russell (use VMLINUX_SYMBOL_STR)

CONFIG_SYMBOL_PREFIX: cleanup.

2013-03-15T04:39:43Z

We have CONFIG_SYMBOL_PREFIX, which three archs define to the string "_". But Al Viro broke this in "consolidate cond_syscall and SYSCALL_ALIAS declarations" (in linux-next), and he's not the first to do so. Using CONFIG_SYMBOL_PREFIX is awkward, since we usually just want to prefix it so something. So various places define helpers which are defined to nothing if CONFIG_SYMBOL_PREFIX isn't set: 1) include/asm-generic/unistd.h defines __SYMBOL_PREFIX. 2) include/asm-generic/vmlinux.lds.h defines VMLINUX_SYMBOL(sym) 3) include/linux/export.h defines MODULE_SYMBOL_PREFIX. 4) include/linux/kernel.h defines SYMBOL_PREFIX (which differs from #7) 5) kernel/modsign_certificate.S defines ASM_SYMBOL(sym) 6) scripts/modpost.c defines MODULE_SYMBOL_PREFIX 7) scripts/Makefile.lib defines SYMBOL_PREFIX on the commandline if CONFIG_SYMBOL_PREFIX is set, so that we have a non-string version for pasting. (arch/h8300/include/asm/linkage.h defines SYMBOL_NAME(), too). Let's solve this properly: 1) No more generic prefix, just CONFIG_HAVE_UNDERSCORE_SYMBOL_PREFIX. 2) Make linux/export.h usable from asm. 3) Define VMLINUX_SYMBOL() and VMLINUX_SYMBOL_STR(). 4) Make everyone use them. Signed-off-by: Rusty Russell Reviewed-by: James Hogan Tested-by: James Hogan (metag)