1. 21 Oct, 2008 8 commits
    • Rusty Russell's avatar
      Make panic= and panic_on_oops into core_params · f44dd164
      Rusty Russell authored
      This allows them to be examined and set after boot, plus means they
      actually give errors if they are misused (eg. panic=yes).
      Signed-off-by: default avatarRusty Russell <rusty@rustcorp.com.au>
      f44dd164
    • Rusty Russell's avatar
      Make initcall_debug a core_param · d0ea3d7d
      Rusty Russell authored
      This is the one I really wanted: now it effects module loading, it
      makes sense to be able to flip it after boot.
      Signed-off-by: default avatarRusty Russell <rusty@rustcorp.com.au>
      Acked-by: default avatarArjan van de Ven <arjan@linux.intel.com>
      d0ea3d7d
    • Rusty Russell's avatar
      core_param() for genuinely core kernel parameters · 67e67cea
      Rusty Russell authored
      There are a lot of one-liner uses of __setup() in the kernel: they're
      cumbersome and not queryable (definitely not settable) via /sys.  Yet
      it's ugly to simplify them to module_param(), because by default that
      inserts a prefix of the module name (usually filename).
      
      So, introduce a "core_param".  The parameter gets no prefix, but
      appears in /sys/module/kernel/parameters/ (if non-zero perms arg).  I
      thought about using the name "core", but that's more common than
      "kernel".  And if you create a module called "kernel", you will die
      a horrible death.
      Signed-off-by: default avatarRusty Russell <rusty@rustcorp.com.au>
      67e67cea
    • Rusty Russell's avatar
      param: Fix duplicate module prefixes · 9b473de8
      Rusty Russell authored
      Instead of insisting each new module_param sysfs entry is unique,
      handle the case where it already exists (for builtin modules).
      
      The current code assumes that all identical prefixes are together in
      the section: true for normal uses, but not necessarily so if someone
      overrides MODULE_PARAM_PREFIX.  More importantly, it's not true with
      the new "core_param()" code which uses "kernel" as a prefix.
      
      This simplifies the caller for the builtin case, at a slight loss of
      efficiency (we do the lookup every time to see if the directory
      exists).
      Signed-off-by: default avatarRusty Russell <rusty@rustcorp.com.au>
      Cc: Greg Kroah-Hartman <gregkh@suse.de>
      9b473de8
    • Rusty Russell's avatar
      module: check kernel param length at compile time, not runtime · 730b69d2
      Rusty Russell authored
      The kparam code tries to handle over-length parameter prefixes at
      runtime.  Not only would I bet this has never been tested, it's not
      clear that truncating names is a good idea either.
      
      So let's check at compile time.  We need to move the #define to
      moduleparam.h to do this, though.
      Signed-off-by: default avatarRusty Russell <rusty@rustcorp.com.au>
      730b69d2
    • Andi Kleen's avatar
      Remove stop_machine during module load v2 · d72b3751
      Andi Kleen authored
      Remove stop_machine during module load v2
      
      module loading currently does a stop_machine on each module load to insert
      the module into the global module lists.  Especially on larger systems this
      can be quite expensive.
      
      It does that to handle concurrent lock lessmodule list readers
      like kallsyms.
      
      I don't think stop_machine() is actually needed to insert something
      into a list though. There are no concurrent writers because the
      module mutex is taken. And the RCU list functions know how to insert
      a node into a list with the right memory ordering so that concurrent
      readers don't go off into the wood.
      
      So remove the stop_machine for the module list insert and just
      do a list_add_rcu() instead.
      
      Module removal will still do a stop_machine of course, it needs
      that for other reasons.
      
      v2: Revised readers based on Paul's comments. All readers that only
          rely on disabled preemption need to be changed to list_for_each_rcu().
          Done that. The others are ok because they have the modules mutex.
          Also added a possible missing preempt disable for print_modules().
      
      [cc Paul McKenney for review. It's not RCU, but quite similar.]
      Acked-by: default avatarPaul E. McKenney <paulmck@linux.vnet.ibm.com>
      Signed-off-by: default avatarRusty Russell <rusty@rustcorp.com.au>
      d72b3751
    • Rusty Russell's avatar
      module: simplify load_module. · 5e458cc0
      Rusty Russell authored
      Linus' recent catch of stack overflow in load_module lead me to look
      at the code.  A couple of helpers to get a section address and get
      objects from a section can help clean things up a little.
      
      (And in case you're wondering, the stack size also dropped from 328 to
      284 bytes).
      Signed-off-by: default avatarRusty Russell <rusty@rustcorp.com.au>
      5e458cc0
    • Paul Mundt's avatar
      binfmt_elf_fdpic: Update for cputime changes. · 2515ddc6
      Paul Mundt authored
      Commit f06febc9 ("timers: fix itimer/
      many thread hang") introduced a new task_cputime interface and
      subsequently only converted binfmt_elf over to it.  This results in the
      build for binfmt_elf_fdpic blowing up given that p->signal->{u,s}time
      have disappeared from underneath us.
      
      Apply the same trivial fix from binfmt_elf to binfmt_elf_fdpic.
      Signed-off-by: default avatarPaul Mundt <lethal@linux-sh.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      2515ddc6
  2. 20 Oct, 2008 32 commits