1. 01 6月, 2010 1 次提交
  2. 26 5月, 2010 1 次提交
  3. 25 5月, 2010 1 次提交
  4. 22 5月, 2010 1 次提交
  5. 21 5月, 2010 1 次提交
  6. 19 5月, 2010 1 次提交
  7. 07 5月, 2010 1 次提交
    • T
      stop_machine: reimplement using cpu_stop · 3fc1f1e2
      Tejun Heo 提交于
      Reimplement stop_machine using cpu_stop.  As cpu stoppers are
      guaranteed to be available for all online cpus,
      stop_machine_create/destroy() are no longer necessary and removed.
      
      With resource management and synchronization handled by cpu_stop, the
      new implementation is much simpler.  Asking the cpu_stop to execute
      the stop_cpu() state machine on all online cpus with cpu hotplug
      disabled is enough.
      
      stop_machine itself doesn't need to manage any global resources
      anymore, so all per-instance information is rolled into struct
      stop_machine_data and the mutex and all static data variables are
      removed.
      
      The previous implementation created and destroyed RT workqueues as
      necessary which made stop_machine() calls highly expensive on very
      large machines.  According to Dimitri Sivanich, preventing the dynamic
      creation/destruction makes booting faster more than twice on very
      large machines.  cpu_stop resources are preallocated for all online
      cpus and should have the same effect.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Acked-by: NRusty Russell <rusty@rustcorp.com.au>
      Acked-by: NPeter Zijlstra <peterz@infradead.org>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: Dimitri Sivanich <sivanich@sgi.com>
      3fc1f1e2
  8. 06 4月, 2010 1 次提交
    • N
      Fix up possibly racy module refcounting · 5fbfb18d
      Nick Piggin 提交于
      Module refcounting is implemented with a per-cpu counter for speed.
      However there is a race when tallying the counter where a reference may
      be taken by one CPU and released by another.  Reference count summation
      may then see the decrement without having seen the previous increment,
      leading to lower than expected count.  A module which never has its
      actual reference drop below 1 may return a reference count of 0 due to
      this race.
      
      Module removal generally runs under stop_machine, which prevents this
      race causing bugs due to removal of in-use modules.  However there are
      other real bugs in module.c code and driver code (module_refcount is
      exported) where the callers do not run under stop_machine.
      
      Fix this by maintaining running per-cpu counters for the number of
      module refcount increments and the number of refcount decrements.  The
      increments are tallied after the decrements, so any decrement seen will
      always have its corresponding increment counted.  The final refcount is
      the difference of the total increments and decrements, preventing a
      low-refcount from being returned.
      Signed-off-by: NNick Piggin <npiggin@suse.de>
      Acked-by: NRusty Russell <rusty@rustcorp.com.au>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      5fbfb18d
  9. 01 4月, 2010 2 次提交
  10. 29 3月, 2010 2 次提交
  11. 08 3月, 2010 1 次提交
  12. 06 1月, 2010 1 次提交
  13. 05 1月, 2010 1 次提交
  14. 15 12月, 2009 1 次提交
  15. 03 12月, 2009 1 次提交
    • H
      modules: don't export section names of empty sections via sysfs · 35dead42
      Helge Deller 提交于
      On the parisc architecture we face for each and every loaded kernel module
      this kernel "badness warning":
        sysfs: cannot create duplicate filename '/module/ac97_bus/sections/.text'
        Badness at fs/sysfs/dir.c:487
      
      Reason for that is, that on parisc all kernel modules do have multiple
      .text sections due to the usage of the -ffunction-sections compiler flag
      which is needed to reach all jump targets on this platform.
      
      An objdump on such a kernel module gives:
      Sections:
      Idx Name          Size      VMA       LMA       File off  Algn
        0 .note.gnu.build-id 00000024  00000000  00000000  00000034  2**2
                        CONTENTS, ALLOC, LOAD, READONLY, DATA
        1 .text         00000000  00000000  00000000  00000058  2**0
                        CONTENTS, ALLOC, LOAD, READONLY, CODE
        2 .text.ac97_bus_match 0000001c  00000000  00000000  00000058  2**2
                        CONTENTS, ALLOC, LOAD, READONLY, CODE
        3 .text         00000000  00000000  00000000  000000d4  2**0
                        CONTENTS, ALLOC, LOAD, READONLY, CODE
      ...
      Since the .text sections are empty (size of 0 bytes) and won't be
      loaded by the kernel module loader anyway, I don't see a reason
      why such sections need to be listed under
      /sys/module/<module_name>/sections/<section_name> either.
      
      The attached patch does solve this issue by not exporting section
      names which are empty.
      
      This fixes bugzilla http://bugzilla.kernel.org/show_bug.cgi?id=14703Signed-off-by: NHelge Deller <deller@gmx.de>
      CC: rusty@rustcorp.com.au
      CC: akpm@linux-foundation.org
      CC: James.Bottomley@HansenPartnership.com
      CC: roland@redhat.com
      CC: dave@hiauly1.hia.nrc.ca
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      35dead42
  16. 29 10月, 2009 1 次提交
  17. 28 10月, 2009 1 次提交
  18. 02 10月, 2009 2 次提交
    • T
      percpu: kill legacy percpu allocator · 23fb064b
      Tejun Heo 提交于
      With ia64 converted, there's no arch left which still uses legacy
      percpu allocator.  Kill it.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Delightedly-acked-by: NRusty Russell <rusty@rustcorp.com.au>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Christoph Lameter <cl@linux-foundation.org>
      23fb064b
    • P
      module: fix up CONFIG_KALLSYMS=n build. · 3ae91c21
      Paul Mundt 提交于
      Starting from commit 4a496226 "reduce
      symbol table for loaded modules (v2)", the kernel/module.c build is broken
      with CONFIG_KALLSYMS disabled.
      
        CC      kernel/module.o
      kernel/module.c:1995: warning: type defaults to 'int' in declaration of 'Elf_Hdr'
      kernel/module.c:1995: error: expected ';', ',' or ')' before '*' token
      kernel/module.c: In function 'load_module':
      kernel/module.c:2203: error: 'strmap' undeclared (first use in this function)
      kernel/module.c:2203: error: (Each undeclared identifier is reported only once
      kernel/module.c:2203: error: for each function it appears in.)
      kernel/module.c:2239: error: 'symoffs' undeclared (first use in this function)
      kernel/module.c:2239: error: implicit declaration of function 'layout_symtab'
      kernel/module.c:2240: error: 'stroffs' undeclared (first use in this function)
      make[1]: *** [kernel/module.o] Error 1
      make: *** [kernel/module.o] Error 2
      
      There are three different issues:
      
          - layout_symtab() takes a const Elf_Ehdr
      
          - layout_symtab() needs to return a value
      
          - symoffs/stroffs/strmap are referenced by the load_module() code
            despite being ifdefed out, which seems unnecessary given the noop
            behaviour of layout_symtab()/add_kallsyms() in the case of
            CONFIG_KALLSYMS=n.
      Signed-off-by: NPaul Mundt <lethal@linux-sh.org>
      Acked-by: NJan Beulich <jbeulich@novell.com>
      Acked-by: NRusty Russell <rusty@rustcorp.com.au>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      3ae91c21
  19. 24 9月, 2009 4 次提交
  20. 23 9月, 2009 1 次提交
    • I
      modules, tracing: Remove stale struct marker signature from module_layout() · 115e8a28
      Ingo Molnar 提交于
      Linus reported this new build warning:
      
        kernel/module.c:2951: warning: ?struct marker? declared inside parameter list
        kernel/module.c:2951: warning: its scope is only this definition or declaration, which is probably not what you want
      
      Caused by:
      
        fc537766: tracing: Remove markers
      
      module_layout() is an artificial symbol with 'significant' symbols
      listed in its argument list so that it gets a proper argument types
      signature that modversions can pick up to decide whether a
      module is version-compatible or not. If these dont match then we
      wont even look at a module.
      
      Remove the stale marker symbol.
      Reported-by: NLinus Torvalds <torvalds@linux-foundation.org>
      LKML-Reference: <alpine.LFD.2.01.0909210908020.4950@localhost.localdomain>
      Cc: Christoph Hellwig <hch@lst.de>
      Cc: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Rusty Russell <rusty@rustcorp.com.au>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      115e8a28
  21. 22 9月, 2009 1 次提交
  22. 19 9月, 2009 1 次提交
  23. 29 8月, 2009 1 次提交
    • I
      modules: Fix build error in the !CONFIG_KALLSYMS case · ea6bff36
      Ingo Molnar 提交于
      > James Bottomley (1):
      >       module: workaround duplicate section names
      
      -tip testing found that this patch breaks the build on x86 if
      CONFIG_KALLSYMS is disabled:
      
       kernel/module.c: In function ‘load_module’:
       kernel/module.c:2367: error: ‘struct module’ has no member named ‘sect_attrs’
       distcc[8269] ERROR: compile kernel/module.c on ph/32 failed
       make[1]: *** [kernel/module.o] Error 1
       make: *** [kernel] Error 2
       make: *** Waiting for unfinished jobs....
      
      Commit 1b364bf4 misses the fact that section attributes are only
      built and dealt with if kallsyms is enabled. The patch below fixes
      this.
      
      ( note, technically speaking this should depend on CONFIG_SYSFS as
        well but this patch is correct too and keeps the #ifdef less
        intrusive - in the KALLSYMS && !SYSFS case the code is a NOP. )
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      [ Replaced patch with a slightly cleaner variation by James Bottomley ]
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      ea6bff36
  24. 28 8月, 2009 2 次提交
  25. 17 8月, 2009 1 次提交
    • L
      tracing/events: Add module tracepoints · 7ead8b83
      Li Zefan 提交于
      Add trace points to trace module_load, module_free, module_get,
      module_put and module_request, and use trace_event facility to
      get the trace output.
      
      Here's the sample output:
      
           TASK-PID    CPU#    TIMESTAMP  FUNCTION
              | |       |          |         |
          <...>-42    [000]     1.758380: module_request: fb0 wait=1 call_site=fb_open
          ...
          <...>-60    [000]     3.269403: module_load: scsi_wait_scan
          <...>-60    [000]     3.269432: module_put: scsi_wait_scan call_site=sys_init_module refcnt=0
          <...>-61    [001]     3.273168: module_free: scsi_wait_scan
          ...
          <...>-1021  [000]    13.836081: module_load: sunrpc
          <...>-1021  [000]    13.840589: module_put: sunrpc call_site=sys_init_module refcnt=-1
          <...>-1027  [000]    13.848098: module_get: sunrpc call_site=try_module_get refcnt=0
          <...>-1027  [000]    13.848308: module_get: sunrpc call_site=get_filesystem refcnt=1
          <...>-1027  [000]    13.848692: module_put: sunrpc call_site=put_filesystem refcnt=0
          ...
       modprobe-2587  [001]  1088.437213: module_load: trace_events_sample F
       modprobe-2587  [001]  1088.437786: module_put: trace_events_sample call_site=sys_init_module refcnt=0
      
      Note:
      
      - the taints flag can be 'F', 'C' and/or 'P' if mod->taints != 0
      
      - the module refcnt is percpu, so it can be negative in a
        specific cpu
      Signed-off-by: NLi Zefan <lizf@cn.fujitsu.com>
      Acked-by: NRusty Russell <rusty@rustcorp.com.au>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Rusty Russell <rusty@rustcorp.com.au>
      LKML-Reference: <4A891B3C.5030608@cn.fujitsu.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      7ead8b83
  26. 28 7月, 2009 1 次提交
  27. 09 7月, 2009 1 次提交
  28. 24 6月, 2009 1 次提交
    • T
      percpu: use dynamic percpu allocator as the default percpu allocator · e74e3962
      Tejun Heo 提交于
      This patch makes most !CONFIG_HAVE_SETUP_PER_CPU_AREA archs use
      dynamic percpu allocator.  The first chunk is allocated using
      embedding helper and 8k is reserved for modules.  This ensures that
      the new allocator behaves almost identically to the original allocator
      as long as static percpu variables are concerned, so it shouldn't
      introduce much breakage.
      
      s390 and alpha use custom SHIFT_PERCPU_PTR() to work around addressing
      range limit the addressing model imposes.  Unfortunately, this breaks
      if the address is specified using a variable, so for now, the two
      archs aren't converted.
      
      The following architectures are affected by this change.
      
      * sh
      * arm
      * cris
      * mips
      * sparc(32)
      * blackfin
      * avr32
      * parisc (broken, under investigation)
      * m32r
      * powerpc(32)
      
      As this change makes the dynamic allocator the default one,
      CONFIG_HAVE_DYNAMIC_PER_CPU_AREA is replaced with its invert -
      CONFIG_HAVE_LEGACY_PER_CPU_AREA, which is added to yet-to-be converted
      archs.  These archs implement their own setup_per_cpu_areas() and the
      conversion is not trivial.
      
      * powerpc(64)
      * sparc(64)
      * ia64
      * alpha
      * s390
      
      Boot and batch alloc/free tests on x86_32 with debug code (x86_32
      doesn't use default first chunk initialization).  Compile tested on
      sparc(32), powerpc(32), arm and alpha.
      
      Kyle McMartin reported that this change breaks parisc.  The problem is
      still under investigation and he is okay with pushing this patch
      forward and fixing parisc later.
      
      [ Impact: use dynamic allocator for most archs w/o custom percpu setup ]
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Acked-by: NRusty Russell <rusty@rustcorp.com.au>
      Acked-by: NDavid S. Miller <davem@davemloft.net>
      Acked-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      Acked-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      Reviewed-by: NChristoph Lameter <cl@linux.com>
      Cc: Paul Mundt <lethal@linux-sh.org>
      Cc: Russell King <rmk@arm.linux.org.uk>
      Cc: Mikael Starvik <starvik@axis.com>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: Bryan Wu <cooloney@kernel.org>
      Cc: Kyle McMartin <kyle@mcmartin.ca>
      Cc: Matthew Wilcox <matthew@wil.cx>
      Cc: Grant Grundler <grundler@parisc-linux.org>
      Cc: Hirokazu Takata <takata@linux-m32r.org>
      Cc: Richard Henderson <rth@twiddle.net>
      Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      e74e3962
  29. 19 6月, 2009 1 次提交
  30. 17 6月, 2009 1 次提交
  31. 12 6月, 2009 2 次提交
    • R
      module: trim exception table on init free. · ad6561df
      Rusty Russell 提交于
      It's theoretically possible that there are exception table entries
      which point into the (freed) init text of modules.  These could cause
      future problems if other modules get loaded into that memory and cause
      an exception as we'd see the wrong fixup.  The only case I know of is
      kvm-intel.ko (when CONFIG_CC_OPTIMIZE_FOR_SIZE=n).
      
      Amerigo fixed this long-standing FIXME in the x86 version, but this
      patch is more general.
      
      This implements trim_init_extable(); most archs are simple since they
      use the standard lib/extable.c sort code.  Alpha and IA64 use relative
      addresses in their fixups, so thier trimming is a slight variation.
      
      Sparc32 is unique; it doesn't seem to define ARCH_HAS_SORT_EXTABLE,
      yet it defines its own sort_extable() which overrides the one in lib.
      It doesn't sort, so we have to mark deleted entries instead of
      actually trimming them.
      Inspired-by: NAmerigo Wang <amwang@redhat.com>
      Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
      Cc: linux-alpha@vger.kernel.org
      Cc: sparclinux@vger.kernel.org
      Cc: linux-ia64@vger.kernel.org
      ad6561df
    • C
      kmemleak: Add modules support · 4f2294b6
      Catalin Marinas 提交于
      This patch handles the kmemleak operations needed for modules loading so
      that memory allocations from inside a module are properly tracked.
      Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>
      4f2294b6
  32. 17 4月, 2009 1 次提交
    • S
      ftrace: use module notifier for function tracer · 93eb677d
      Steven Rostedt 提交于
      The hooks in the module code for the function tracer must be called
      before any of that module code runs. The function tracer hooks
      modify the module (replacing calls to mcount to nops). If the code
      is executed while the change occurs, then the CPU can take a GPF.
      
      To handle the above with a bit of paranoia, I originally implemented
      the hooks as calls directly from the module code.
      
      After examining the notifier calls, it looks as though the start up
      notify is called before any of the module's code is executed. This makes
      the use of the notify safe with ftrace.
      
      Only the startup notify is required to be "safe". The shutdown simply
      removes the entries from the ftrace function list, and does not modify
      any code.
      
      This change has another benefit. It removes a issue with a reverse dependency
      in the mutexes of ftrace_lock and module_mutex.
      
      [ Impact: fix lock dependency bug, cleanup ]
      
      Cc: Rusty Russell <rusty@rustcorp.com.au>
      Signed-off-by: NSteven Rostedt <rostedt@goodmis.org>
      93eb677d