1. 29 10月, 2009 1 次提交
    • T
      percpu: make percpu symbols under kernel/ and mm/ unique · 1871e52c
      Tejun Heo 提交于
      This patch updates percpu related symbols under kernel/ and mm/ such
      that percpu symbols are unique and don't clash with local symbols.
      This serves two purposes of decreasing the possibility of global
      percpu symbol collision and allowing dropping per_cpu__ prefix from
      percpu symbols.
      
      * kernel/lockdep.c: s/lock_stats/cpu_lock_stats/
      
      * kernel/sched.c: s/init_rq_rt/init_rt_rq_var/	(any better idea?)
        		  s/sched_group_cpus/sched_groups/
      
      * kernel/softirq.c: s/ksoftirqd/run_ksoftirqd/a
      
      * kernel/softlockup.c: s/(*)_timestamp/softlockup_\1_ts/
        		       s/watchdog_task/softlockup_watchdog/
      		       s/timestamp/ts/ for local variables
      
      * kernel/time/timer_stats: s/lookup_lock/tstats_lookup_lock/
      
      * mm/slab.c: s/reap_work/slab_reap_work/
        	     s/reap_node/slab_reap_node/
      
      * mm/vmstat.c: local variable changed to avoid collision with vmstat_work
      
      Partly based on Rusty Russell's "alloc_percpu: rename percpu vars
      which cause name clashes" patch.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Acked-by: N(slab/vmstat) Christoph Lameter <cl@linux-foundation.org>
      Reviewed-by: NChristoph Lameter <cl@linux-foundation.org>
      Cc: Rusty Russell <rusty@rustcorp.com.au>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Nick Piggin <npiggin@suse.de>
      1871e52c
  2. 22 9月, 2009 1 次提交
  3. 29 6月, 2009 1 次提交
    • P
      SLAB: Fix lockdep annotations · ec5a36f9
      Pekka Enberg 提交于
      Commit 8429db5c... ("slab: setup cpu caches later on when interrupts are
      enabled") broke mm/slab.c lockdep annotations:
      
        [   11.554715] =============================================
        [   11.555249] [ INFO: possible recursive locking detected ]
        [   11.555560] 2.6.31-rc1 #896
        [   11.555861] ---------------------------------------------
        [   11.556127] udevd/1899 is trying to acquire lock:
        [   11.556436]  (&nc->lock){-.-...}, at: [<ffffffff810c337f>] kmem_cache_free+0xcd/0x25b
        [   11.557101]
        [   11.557102] but task is already holding lock:
        [   11.557706]  (&nc->lock){-.-...}, at: [<ffffffff810c3cd0>] kfree+0x137/0x292
        [   11.558109]
        [   11.558109] other info that might help us debug this:
        [   11.558720] 2 locks held by udevd/1899:
        [   11.558983]  #0:  (&nc->lock){-.-...}, at: [<ffffffff810c3cd0>] kfree+0x137/0x292
        [   11.559734]  #1:  (&parent->list_lock){-.-...}, at: [<ffffffff810c36c7>] __drain_alien_cache+0x3b/0xbd
        [   11.560442]
        [   11.560443] stack backtrace:
        [   11.561009] Pid: 1899, comm: udevd Not tainted 2.6.31-rc1 #896
        [   11.561276] Call Trace:
        [   11.561632]  [<ffffffff81065ed6>] __lock_acquire+0x15ec/0x168f
        [   11.561901]  [<ffffffff81065f60>] ? __lock_acquire+0x1676/0x168f
        [   11.562171]  [<ffffffff81063c52>] ? trace_hardirqs_on_caller+0x113/0x13e
        [   11.562490]  [<ffffffff8150c337>] ? trace_hardirqs_on_thunk+0x3a/0x3f
        [   11.562807]  [<ffffffff8106603a>] lock_acquire+0xc1/0xe5
        [   11.563073]  [<ffffffff810c337f>] ? kmem_cache_free+0xcd/0x25b
        [   11.563385]  [<ffffffff8150c8fc>] _spin_lock+0x31/0x66
        [   11.563696]  [<ffffffff810c337f>] ? kmem_cache_free+0xcd/0x25b
        [   11.563964]  [<ffffffff810c337f>] kmem_cache_free+0xcd/0x25b
        [   11.564235]  [<ffffffff8109bf8c>] ? __free_pages+0x1b/0x24
        [   11.564551]  [<ffffffff810c3564>] slab_destroy+0x57/0x5c
        [   11.564860]  [<ffffffff810c3641>] free_block+0xd8/0x123
        [   11.565126]  [<ffffffff810c372e>] __drain_alien_cache+0xa2/0xbd
        [   11.565441]  [<ffffffff810c3ce5>] kfree+0x14c/0x292
        [   11.565752]  [<ffffffff8144a007>] skb_release_data+0xc6/0xcb
        [   11.566020]  [<ffffffff81449cf0>] __kfree_skb+0x19/0x86
        [   11.566286]  [<ffffffff81449d88>] consume_skb+0x2b/0x2d
        [   11.566631]  [<ffffffff8144cbe0>] skb_free_datagram+0x14/0x3a
        [   11.566901]  [<ffffffff81462eef>] netlink_recvmsg+0x164/0x258
        [   11.567170]  [<ffffffff81443461>] sock_recvmsg+0xe5/0xfe
        [   11.567486]  [<ffffffff810ab063>] ? might_fault+0xaf/0xb1
        [   11.567802]  [<ffffffff81053a78>] ? autoremove_wake_function+0x0/0x38
        [   11.568073]  [<ffffffff810d84ca>] ? core_sys_select+0x3d/0x2b4
        [   11.568378]  [<ffffffff81065f60>] ? __lock_acquire+0x1676/0x168f
        [   11.568693]  [<ffffffff81442dc1>] ? sockfd_lookup_light+0x1b/0x54
        [   11.568961]  [<ffffffff81444416>] sys_recvfrom+0xa3/0xf8
        [   11.569228]  [<ffffffff81063c8a>] ? trace_hardirqs_on+0xd/0xf
        [   11.569546]  [<ffffffff8100af2b>] system_call_fastpath+0x16/0x1b#
      
      Fix that up.
      
      Closes-bug: http://bugzilla.kernel.org/show_bug.cgi?id=13654Tested-by: NVenkatesh Pallipadi <venkatesh.pallipadi@intel.com>
      Signed-off-by: NPekka Enberg <penberg@cs.helsinki.fi>
      ec5a36f9
  4. 26 6月, 2009 1 次提交
  5. 19 6月, 2009 1 次提交
  6. 17 6月, 2009 2 次提交
  7. 15 6月, 2009 2 次提交
  8. 13 6月, 2009 1 次提交
  9. 12 6月, 2009 5 次提交
    • P
      slab: setup cpu caches later on when interrupts are enabled · 8429db5c
      Pekka Enberg 提交于
      Fixes the following boot-time warning:
      
        [    0.000000] ------------[ cut here ]------------
        [    0.000000] WARNING: at kernel/smp.c:369 smp_call_function_many+0x56/0x1bc()
        [    0.000000] Hardware name:
        [    0.000000] Modules linked in:
        [    0.000000] Pid: 0, comm: swapper Not tainted 2.6.30 #492
        [    0.000000] Call Trace:
        [    0.000000]  [<ffffffff8149e021>] ? _spin_unlock+0x4f/0x5c
        [    0.000000]  [<ffffffff8108f11b>] ? smp_call_function_many+0x56/0x1bc
        [    0.000000]  [<ffffffff81061764>] warn_slowpath_common+0x7c/0xa9
        [    0.000000]  [<ffffffff810617a5>] warn_slowpath_null+0x14/0x16
        [    0.000000]  [<ffffffff8108f11b>] smp_call_function_many+0x56/0x1bc
        [    0.000000]  [<ffffffff810f3e00>] ? do_ccupdate_local+0x0/0x54
        [    0.000000]  [<ffffffff810f3e00>] ? do_ccupdate_local+0x0/0x54
        [    0.000000]  [<ffffffff8108f2be>] smp_call_function+0x3d/0x68
        [    0.000000]  [<ffffffff810f3e00>] ? do_ccupdate_local+0x0/0x54
        [    0.000000]  [<ffffffff81066fd8>] on_each_cpu+0x31/0x7c
        [    0.000000]  [<ffffffff810f64f5>] do_tune_cpucache+0x119/0x454
        [    0.000000]  [<ffffffff81087080>] ? lockdep_init_map+0x94/0x10b
        [    0.000000]  [<ffffffff818133b0>] ? kmem_cache_init+0x421/0x593
        [    0.000000]  [<ffffffff810f69cf>] enable_cpucache+0x68/0xad
        [    0.000000]  [<ffffffff818133c3>] kmem_cache_init+0x434/0x593
        [    0.000000]  [<ffffffff8180987c>] ? mem_init+0x156/0x161
        [    0.000000]  [<ffffffff817f8aae>] start_kernel+0x1cc/0x3b9
        [    0.000000]  [<ffffffff817f829a>] x86_64_start_reservations+0xaa/0xae
        [    0.000000]  [<ffffffff817f837f>] x86_64_start_kernel+0xe1/0xe8
        [    0.000000] ---[ end trace 4eaa2a86a8e2da22 ]---
      
      Cc: Christoph Lameter <cl@linux-foundation.org>
      Cc: Nick Piggin <npiggin@suse.de>
      Signed-off-by: NPekka Enberg <penberg@cs.helsinki.fi>
      8429db5c
    • P
      slab,slub: don't enable interrupts during early boot · 7e85ee0c
      Pekka Enberg 提交于
      As explained by Benjamin Herrenschmidt:
      
        Oh and btw, your patch alone doesn't fix powerpc, because it's missing
        a whole bunch of GFP_KERNEL's in the arch code... You would have to
        grep the entire kernel for things that check slab_is_available() and
        even then you'll be missing some.
      
        For example, slab_is_available() didn't always exist, and so in the
        early days on powerpc, we used a mem_init_done global that is set form
        mem_init() (not perfect but works in practice). And we still have code
        using that to do the test.
      
      Therefore, mask out __GFP_WAIT, __GFP_IO, and __GFP_FS in the slab allocators
      in early boot code to avoid enabling interrupts.
      Signed-off-by: NPekka Enberg <penberg@cs.helsinki.fi>
      7e85ee0c
    • P
      slab: fix gfp flag in setup_cpu_cache() · eb91f1d0
      Pekka Enberg 提交于
      Fixes the following warning during bootup when compiling with CONFIG_SLAB:
      
        [    0.000000] ------------[ cut here ]------------
        [    0.000000] WARNING: at kernel/lockdep.c:2282 lockdep_trace_alloc+0x91/0xb9()
        [    0.000000] Hardware name:
        [    0.000000] Modules linked in:
        [    0.000000] Pid: 0, comm: swapper Not tainted 2.6.30 #491
        [    0.000000] Call Trace:
        [    0.000000]  [<ffffffff81087d84>] ? lockdep_trace_alloc+0x91/0xb9
        [    0.000000]  [<ffffffff81061764>] warn_slowpath_common+0x7c/0xa9
        [    0.000000]  [<ffffffff810617a5>] warn_slowpath_null+0x14/0x16
        [    0.000000]  [<ffffffff81087d84>] lockdep_trace_alloc+0x91/0xb9
        [    0.000000]  [<ffffffff810f5b03>] kmem_cache_alloc_node_notrace+0x26/0xdf
        [    0.000000]  [<ffffffff81487f4e>] ? setup_cpu_cache+0x7e/0x210
        [    0.000000]  [<ffffffff81487fe3>] setup_cpu_cache+0x113/0x210
        [    0.000000]  [<ffffffff810f73ff>] kmem_cache_create+0x409/0x486
        [    0.000000]  [<ffffffff818131c1>] kmem_cache_init+0x232/0x593
        [    0.000000]  [<ffffffff8180987c>] ? mem_init+0x156/0x161
        [    0.000000]  [<ffffffff817f8aae>] start_kernel+0x1cc/0x3b9
        [    0.000000]  [<ffffffff817f829a>] x86_64_start_reservations+0xaa/0xae
        [    0.000000]  [<ffffffff817f837f>] x86_64_start_kernel+0xe1/0xe8
        [    0.000000] ---[ end trace 4eaa2a86a8e2da22 ]---
      Signed-off-by: NPekka Enberg <penberg@cs.helsinki.fi>
      eb91f1d0
    • P
      slab: setup allocators earlier in the boot sequence · 83b519e8
      Pekka Enberg 提交于
      This patch makes kmalloc() available earlier in the boot sequence so we can get
      rid of some bootmem allocations. The bulk of the changes are due to
      kmem_cache_init() being called with interrupts disabled which requires some
      changes to allocator boostrap code.
      
      Note: 32-bit x86 does WP protect test in mem_init() so we must setup traps
      before we call mem_init() during boot as reported by Ingo Molnar:
      
        We have a hard crash in the WP-protect code:
      
        [    0.000000] Checking if this processor honours the WP bit even in supervisor mode...BUG: Int 14: CR2 ffcff000
        [    0.000000]      EDI 00000188  ESI 00000ac7  EBP c17eaf9c  ESP c17eaf8c
        [    0.000000]      EBX 000014e0  EDX 0000000e  ECX 01856067  EAX 00000001
        [    0.000000]      err 00000003  EIP c10135b1   CS 00000060  flg 00010002
        [    0.000000] Stack: c17eafa8 c17fd410 c16747bc c17eafc4 c17fd7e5 000011fd f8616000 c18237cc
        [    0.000000]        00099800 c17bb000 c17eafec c17f1668 000001c5 c17f1322 c166e039 c1822bf0
        [    0.000000]        c166e033 c153a014 c18237cc 00020800 c17eaff8 c17f106a 00020800 01ba5003
        [    0.000000] Pid: 0, comm: swapper Not tainted 2.6.30-tip-02161-g7a74539-dirty #52203
        [    0.000000] Call Trace:
        [    0.000000]  [<c15357c2>] ? printk+0x14/0x16
        [    0.000000]  [<c10135b1>] ? do_test_wp_bit+0x19/0x23
        [    0.000000]  [<c17fd410>] ? test_wp_bit+0x26/0x64
        [    0.000000]  [<c17fd7e5>] ? mem_init+0x1ba/0x1d8
        [    0.000000]  [<c17f1668>] ? start_kernel+0x164/0x2f7
        [    0.000000]  [<c17f1322>] ? unknown_bootoption+0x0/0x19c
        [    0.000000]  [<c17f106a>] ? __init_begin+0x6a/0x6f
      Acked-by: NJohannes Weiner <hannes@cmpxchg.org>
      Acked-by Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Christoph Lameter <cl@linux-foundation.org>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Matt Mackall <mpm@selenic.com>
      Cc: Nick Piggin <npiggin@suse.de>
      Cc: Yinghai Lu <yinghai@kernel.org>
      Signed-off-by: NPekka Enberg <penberg@cs.helsinki.fi>
      83b519e8
    • C
      kmemleak: Add the slab memory allocation/freeing hooks · d5cff635
      Catalin Marinas 提交于
      This patch adds the callbacks to kmemleak_(alloc|free) functions from
      the slab allocator. The patch also adds the SLAB_NOLEAKTRACE flag to
      avoid recursive calls to kmemleak when it allocates its own data
      structures.
      Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>
      Reviewed-by: NPekka Enberg <penberg@cs.helsinki.fi>
      d5cff635
  10. 22 5月, 2009 1 次提交
    • R
      slab: fix generic PAGE_POISONING conflict with SLAB_RED_ZONE · 67461365
      Ron Lee 提交于
      A generic page poisoning mechanism was added with commit:
       6a11f75b
      which destructively poisons full pages with a bitpattern.
      
      On arches where PAGE_POISONING is used, this conflicts with the slab
      redzone checking enabled by DEBUG_SLAB, scribbling bits all over its
      magic words and making it complain about that quite emphatically.
      
      On x86 (and I presume at present all the other arches which set
      ARCH_SUPPORTS_DEBUG_PAGEALLOC too), the kernel_map_pages() operation
      is non destructive so it can coexist with the other DEBUG_SLAB
      mechanisms just fine.
      
      This patch favours the expensive full page destruction test for
      cases where there is a collision and it is explicitly selected.
      Signed-off-by: NRon Lee <ron@debian.org>
      Signed-off-by: NPekka Enberg <penberg@cs.helsinki.fi>
      67461365
  11. 12 4月, 2009 1 次提交
  12. 03 4月, 2009 3 次提交
  13. 13 3月, 2009 1 次提交
  14. 15 2月, 2009 1 次提交
    • N
      lockdep: annotate reclaim context (__GFP_NOFS) · cf40bd16
      Nick Piggin 提交于
      Here is another version, with the incremental patch rolled up, and
      added reclaim context annotation to kswapd, and allocation tracing
      to slab allocators (which may only ever reach the page allocator
      in rare cases, so it is good to put annotations here too).
      
      Haven't tested this version as such, but it should be getting closer
      to merge worthy ;)
      
      --
      After noticing some code in mm/filemap.c accidentally perform a __GFP_FS
      allocation when it should not have been, I thought it might be a good idea to
      try to catch this kind of thing with lockdep.
      
      I coded up a little idea that seems to work. Unfortunately the system has to
      actually be in __GFP_FS page reclaim, then take the lock, before it will mark
      it. But at least that might still be some orders of magnitude more common
      (and more debuggable) than an actual deadlock condition, so we have some
      improvement I hope (the concept is no less complete than discovery of a lock's
      interrupt contexts).
      
      I guess we could even do the same thing with __GFP_IO (normal reclaim), and
      even GFP_NOIO locks too... but filesystems will have the most locks and fiddly
      code paths, so let's start there and see how it goes.
      
      It *seems* to work. I did a quick test.
      
      =================================
      [ INFO: inconsistent lock state ]
      2.6.28-rc6-00007-ged313489-dirty #26
      ---------------------------------
      inconsistent {in-reclaim-W} -> {ov-reclaim-W} usage.
      modprobe/8526 [HC0[0]:SC0[0]:HE1:SE1] takes:
       (testlock){--..}, at: [<ffffffffa0020055>] brd_init+0x55/0x216 [brd]
      {in-reclaim-W} state was registered at:
        [<ffffffff80267bdb>] __lock_acquire+0x75b/0x1a60
        [<ffffffff80268f71>] lock_acquire+0x91/0xc0
        [<ffffffff8070f0e1>] mutex_lock_nested+0xb1/0x310
        [<ffffffffa002002b>] brd_init+0x2b/0x216 [brd]
        [<ffffffff8020903b>] _stext+0x3b/0x170
        [<ffffffff80272ebf>] sys_init_module+0xaf/0x1e0
        [<ffffffff8020c3fb>] system_call_fastpath+0x16/0x1b
        [<ffffffffffffffff>] 0xffffffffffffffff
      irq event stamp: 3929
      hardirqs last  enabled at (3929): [<ffffffff8070f2b5>] mutex_lock_nested+0x285/0x310
      hardirqs last disabled at (3928): [<ffffffff8070f089>] mutex_lock_nested+0x59/0x310
      softirqs last  enabled at (3732): [<ffffffff8061f623>] sk_filter+0x83/0xe0
      softirqs last disabled at (3730): [<ffffffff8061f5b6>] sk_filter+0x16/0xe0
      
      other info that might help us debug this:
      1 lock held by modprobe/8526:
       #0:  (testlock){--..}, at: [<ffffffffa0020055>] brd_init+0x55/0x216 [brd]
      
      stack backtrace:
      Pid: 8526, comm: modprobe Not tainted 2.6.28-rc6-00007-ged313489-dirty #26
      Call Trace:
       [<ffffffff80265483>] print_usage_bug+0x193/0x1d0
       [<ffffffff80266530>] mark_lock+0xaf0/0xca0
       [<ffffffff80266735>] mark_held_locks+0x55/0xc0
       [<ffffffffa0020000>] ? brd_init+0x0/0x216 [brd]
       [<ffffffff802667ca>] trace_reclaim_fs+0x2a/0x60
       [<ffffffff80285005>] __alloc_pages_internal+0x475/0x580
       [<ffffffff8070f29e>] ? mutex_lock_nested+0x26e/0x310
       [<ffffffffa0020000>] ? brd_init+0x0/0x216 [brd]
       [<ffffffffa002006a>] brd_init+0x6a/0x216 [brd]
       [<ffffffffa0020000>] ? brd_init+0x0/0x216 [brd]
       [<ffffffff8020903b>] _stext+0x3b/0x170
       [<ffffffff8070f8b9>] ? mutex_unlock+0x9/0x10
       [<ffffffff8070f83d>] ? __mutex_unlock_slowpath+0x10d/0x180
       [<ffffffff802669ec>] ? trace_hardirqs_on_caller+0x12c/0x190
       [<ffffffff80272ebf>] sys_init_module+0xaf/0x1e0
       [<ffffffff8020c3fb>] system_call_fastpath+0x16/0x1b
      Signed-off-by: NNick Piggin <npiggin@suse.de>
      Signed-off-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      cf40bd16
  15. 12 2月, 2009 1 次提交
  16. 01 1月, 2009 1 次提交
  17. 31 12月, 2008 1 次提交
  18. 30 12月, 2008 2 次提交
  19. 29 12月, 2008 4 次提交
  20. 26 11月, 2008 3 次提交
  21. 23 10月, 2008 2 次提交
  22. 30 7月, 2008 1 次提交
  23. 27 7月, 2008 1 次提交
  24. 16 7月, 2008 1 次提交
  25. 26 6月, 2008 1 次提交