linux-toradex.git/kernel/module.c, branch v2.6.36.4

modules: Fix module_bug_list list corruption race

2010-10-05T18:29:27+00:00

With all the recent module loading cleanups, we've minimized the code
that sits under module_mutex, fixing various deadlocks and making it
possible to do most of the module loading in parallel.

However, that whole conversion totally missed the rather obscure code
that adds a new module to the list for BUG() handling.  That code was
doubly obscure because (a) the code itself lives in lib/bugs.c (for
dubious reasons) and (b) it gets called from the architecture-specific
"module_finalize()" rather than from generic code.

Calling it from arch-specific code makes no sense what-so-ever to begin
with, and is now actively wrong since that code isn't protected by the
module loading lock any more.

So this commit moves the "module_bug_{finalize,cleanup}()" calls away
from the arch-specific code, and into the generic code - and in the
process protects it with the module_mutex so that the list operations
are now safe.

Future fixups:
 - move the module list handling code into kernel/module.c where it
   belongs.
 - get rid of 'module_bug_list' and just use the regular list of modules
   (called 'modules' - imagine that) that we already create and maintain
   for other reasons.

Reported-and-tested-by: Thomas Gleixner 
Cc: Rusty Russell 
Cc: Adrian Bunk 
Cc: Andrew Morton 
Cc: stable@kernel.org
Signed-off-by: Linus Torvalds

module: cleanup comments, remove noinline

2010-08-05T03:29:13+00:00

On my (32-bit x86) machine, sys_init_module() uses 124 bytes of stack
once load_module() is inlined.

This effectively reverts ffb4ba76 which inlined it due to stack
pressure.

Signed-off-by: Rusty Russell

module: group post-relocation functions into post_relocation()

2010-08-05T03:29:13+00:00

This simply hoists more code out of load_module; we also put the
identification of the extable and dynamic debug table in with the
others in find_module_sections().

We move the taint check to the actual add/remove of the dynamic debug
info: this is certain (find_module_sections is too early).

Signed-off-by: Rusty Russell 
Cc: Yehuda Sadeh

module: move module args strndup_user to just before use

2010-08-05T03:29:12+00:00

Instead of copying and allocating the args and storing it in
load_info, we can just allocate them right before we need them.

Signed-off-by: Rusty Russell

module: pass load_info into other functions

2010-08-05T03:29:10+00:00

Pass the struct load_info into all the other functions in module
loading.  This neatens things and makes them more consistent.

Signed-off-by: Rusty Russell

module: fix sysfs cleanup for !CONFIG_SYSFS

2010-08-05T03:29:10+00:00

Restore the stub module_remove_modinfo_attrs, remove the now-unused
!CONFIG_SYSFS module_sysfs_init.

Also, rename mod_kobject_remove() to mod_sysfs_teardown() as
it is the logical counterpart to mod_sysfs_setup now.

Reported-by: Randy Dunlap 
Signed-off-by: Rusty Russell

module: sysfs cleanup

2010-08-05T03:29:09+00:00

We change the sysfs functions to take struct load_info, and call
them all in mod_sysfs_setup().

We also clean up the #ifdefs a little.

Signed-off-by: Rusty Russell

module: layout_and_allocate

2010-08-05T03:29:09+00:00

layout_and_allocate() does everything up to and including the final
struct module placement inside the allocated module memory.  We have
to store the symbol layout information in our struct load_info though.

This avoids the nasty code we had before where 'mod' pointed first
to the version inside the temporary allocation containing the entire
file, then later was moved to point to the real struct module: now
the main code only ever sees the final module address.

(Includes fix for the Tony Luck-found Linus-diagnosed failure path
 error).

Signed-off-by: Rusty Russell

module: fix crash in get_ksymbol() when oopsing in module init

2010-08-05T03:29:08+00:00

Andrew had the sole pleasure of tickling this bug in linux-next; when we set
up "info->strtab" it's pointing into the temporary copy of the module.  For
most uses that is fine, but kallsyms keeps a pointer around during module
load (inside mod->strtab).

If we oops for some reason inside a module's init function, kallsyms will use
the mod->strtab pointer into the now-freed temporary module copy.

(Later oopses work fine: after init we overwrite mod->strtab to point to a
 compacted core-only strtab).

Reported-by: Andrew "Grumpy" Morton 
Signed-off-by: Rusty "Buggy" Russell 
Tested-by: Andrew "Happy" Morton 
Signed-off-by: Rusty Russell

module: kallsyms functions take struct load_info

2010-08-05T03:29:08+00:00

Simple refactor causes us to lift struct definition to top of file.

Signed-off-by: Rusty Russell