1. 26 Oct, 2010 1 commit
  2. 10 Aug, 2010 1 commit
  3. 09 Aug, 2010 1 commit
    • Carsten Otte's avatar
      slab: fix object alignment · 1ab335d8
      Carsten Otte authored
      This patch fixes alignment of slab objects in case CONFIG_DEBUG_PAGEALLOC is
      active.
      Before this spot in kmem_cache_create, we have this situation:
      - align contains the required alignment of the object
      - cachep->obj_offset is 0 or equals align in case of CONFIG_DEBUG_SLAB
      - size equals the size of the object, or object plus trailing redzone in case
        of CONFIG_DEBUG_SLAB
      
      This spot tries to fill one page per object if the object is in certain size
      limits, however setting obj_offset to PAGE_SIZE - size does break the object
      alignment since size may not be aligned with the required alignment.
      This patch simply adds an ALIGN(size, align) to the equation and fixes the
      object size detection accordingly.
      
      This code in drivers/s390/cio/qdio_setup_init has lead to incorrectly aligned
      slab objects (sizeof(struct qdio_q) equals 1792):
      	qdio_q_cache = kmem_cache_create("qdio_q", sizeof(struct qdio_q),
      					 256, 0, NULL);
      Acked-by: default avatarChristoph Lameter <cl@linux.com>
      Signed-off-by: default avatarCarsten Otte <cotte@de.ibm.com>
      Signed-off-by: default avatarPekka Enberg <penberg@kernel.org>
      1ab335d8
  4. 20 Jul, 2010 1 commit
    • Arjan van de Ven's avatar
      slab: use deferable timers for its periodic housekeeping · 78b43536
      Arjan van de Ven authored
      slab has a "once every 2 second" timer for its housekeeping.
      As the number of logical processors is growing, its more and more
      common that this 2 second timer becomes the primary wakeup source.
      
      This patch turns this housekeeping timer into a deferable timer,
      which means that the timer does not interrupt idle, but just runs
      at the next event that wakes the cpu up.
      
      The impact is that the timer likely runs a bit later, but during the
      delay no code is running so there's not all that much reason for
      a difference in housekeeping to occur because of this delay.
      Signed-off-by: default avatarArjan van de Ven <arjan@linux.intel.com>
      Signed-off-by: default avatarPekka Enberg <penberg@cs.helsinki.fi>
      78b43536
  5. 09 Jun, 2010 1 commit
  6. 27 May, 2010 3 commits
    • Lee Schermerhorn's avatar
      numa: slab: use numa_mem_id() for slab local memory node · 7d6e6d09
      Lee Schermerhorn authored
      Example usage of generic "numa_mem_id()":
      
      The mainline slab code, since ~ 2.6.19, does not handle memoryless nodes
      well.  Specifically, the "fast path"--____cache_alloc()--will never
      succeed as slab doesn't cache offnode object on the per cpu queues, and
      for memoryless nodes, all memory will be "off node" relative to
      numa_node_id().  This adds significant overhead to all kmem cache
      allocations, incurring a significant regression relative to earlier
      kernels [from before slab.c was reorganized].
      
      This patch uses the generic topology function "numa_mem_id()" to return
      the "effective local memory node" for the calling context.  This is the
      first node in the local node's generic fallback zonelist-- the same node
      that "local" mempolicy-based allocations would use.  This lets slab cache
      these "local" allocations and avoid fallback/refill on every allocation.
      
      N.B.: Slab will need to handle node and memory hotplug events that could
      change the value returned by numa_mem_id() for any given node if recent
      changes to address memory hotplug don't already address this.  E.g., flush
      all per cpu slab queues before rebuilding the zonelists while the
      "machine" is held in the stopped state.
      
      Performance impact on "hackbench 400 process 200"
      
      2.6.34-rc3-mmotm-100405-1609		no-patch	this-patch
      ia64 no memoryless nodes [avg of 10]:     11.713       11.637  ~0.65 diff
      ia64 cpus all on memless nodes  [10]:    228.259       26.484  ~8.6x speedup
      
      The slowdown of the patched kernel from ~12 sec to ~28 seconds when
      configured with memoryless nodes is the result of all cpus allocating from
      a single node's mm pagepool.  The cache lines of the single node are
      distributed/interleaved over the memory of the real physical nodes, but
      the zone lock, list heads, ...  of the single node with memory still each
      live in a single cache line that is accessed from all processors.
      
      x86_64 [8x6 AMD] [avg of 40]:		2.883	   2.845
      Signed-off-by: default avatarLee Schermerhorn <lee.schermerhorn@hp.com>
      Cc: Tejun Heo <tj@kernel.org>
      Cc: Mel Gorman <mel@csn.ul.ie>
      Cc: Christoph Lameter <cl@linux-foundation.org>
      Cc: Nick Piggin <npiggin@suse.de>
      Cc: David Rientjes <rientjes@google.com>
      Cc: Eric Whitney <eric.whitney@hp.com>
      Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: "Luck, Tony" <tony.luck@intel.com>
      Cc: Pekka Enberg <penberg@cs.helsinki.fi>
      Cc: <linux-arch@vger.kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      7d6e6d09
    • Akinobu Mita's avatar
      slab: convert cpu notifier to return encapsulate errno value · eac40680
      Akinobu Mita authored
      By the previous modification, the cpu notifier can return encapsulate
      errno value.  This converts the cpu notifiers for slab.
      Signed-off-by: default avatarAkinobu Mita <akinobu.mita@gmail.com>
      Cc: Christoph Lameter <cl@linux-foundation.org>
      Acked-by: default avatarPekka Enberg <penberg@cs.helsinki.fi>
      Cc: Matt Mackall <mpm@selenic.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      eac40680
    • Jack Steiner's avatar
      cpusets: new round-robin rotor for SLAB allocations · 6adef3eb
      Jack Steiner authored
      We have observed several workloads running on multi-node systems where
      memory is assigned unevenly across the nodes in the system.  There are
      numerous reasons for this but one is the round-robin rotor in
      cpuset_mem_spread_node().
      
      For example, a simple test that writes a multi-page file will allocate
      pages on nodes 0 2 4 6 ...  Odd nodes are skipped.  (Sometimes it
      allocates on odd nodes & skips even nodes).
      
      An example is shown below.  The program "lfile" writes a file consisting
      of 10 pages.  The program then mmaps the file & uses get_mempolicy(...,
      MPOL_F_NODE) to determine the nodes where the file pages were allocated.
      The output is shown below:
      
      	# ./lfile
      	 allocated on nodes: 2 4 6 0 1 2 6 0 2
      
      There is a single rotor that is used for allocating both file pages & slab
      pages.  Writing the file allocates both a data page & a slab page
      (buffer_head).  This advances the RR rotor 2 nodes for each page
      allocated.
      
      A quick confirmation seems to confirm this is the cause of the uneven
      allocation:
      
      	# echo 0 >/dev/cpuset/memory_spread_slab
      	# ./lfile
      	 allocated on nodes: 6 7 8 9 0 1 2 3 4 5
      
      This patch introduces a second rotor that is used for slab allocations.
      Signed-off-by: default avatarJack Steiner <steiner@sgi.com>
      Acked-by: default avatarChristoph Lameter <cl@linux-foundation.org>
      Cc: Pekka Enberg <penberg@cs.helsinki.fi>
      Cc: Paul Menage <menage@google.com>
      Cc: Jack Steiner <steiner@sgi.com>
      Cc: Robin Holt <holt@sgi.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      6adef3eb
  7. 25 May, 2010 1 commit
    • Miao Xie's avatar
      cpuset,mm: fix no node to alloc memory when changing cpuset's mems · c0ff7453
      Miao Xie authored
      Before applying this patch, cpuset updates task->mems_allowed and
      mempolicy by setting all new bits in the nodemask first, and clearing all
      old unallowed bits later.  But in the way, the allocator may find that
      there is no node to alloc memory.
      
      The reason is that cpuset rebinds the task's mempolicy, it cleans the
      nodes which the allocater can alloc pages on, for example:
      
      (mpol: mempolicy)
      	task1			task1's mpol	task2
      	alloc page		1
      	  alloc on node0? NO	1
      				1		change mems from 1 to 0
      				1		rebind task1's mpol
      				0-1		  set new bits
      				0	  	  clear disallowed bits
      	  alloc on node1? NO	0
      	  ...
      	can't alloc page
      	  goto oom
      
      This patch fixes this problem by expanding the nodes range first(set newly
      allowed bits) and shrink it lazily(clear newly disallowed bits).  So we
      use a variable to tell the write-side task that read-side task is reading
      nodemask, and the write-side task clears newly disallowed nodes after
      read-side task ends the current memory allocation.
      
      [akpm@linux-foundation.org: fix spello]
      Signed-off-by: default avatarMiao Xie <miaox@cn.fujitsu.com>
      Cc: David Rientjes <rientjes@google.com>
      Cc: Nick Piggin <npiggin@suse.de>
      Cc: Paul Menage <menage@google.com>
      Cc: Lee Schermerhorn <lee.schermerhorn@hp.com>
      Cc: Hugh Dickins <hugh.dickins@tiscali.co.uk>
      Cc: Ravikiran Thirumalai <kiran@scalex86.org>
      Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
      Cc: Christoph Lameter <cl@linux-foundation.org>
      Cc: Andi Kleen <andi@firstfloor.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      c0ff7453
  8. 19 May, 2010 1 commit
  9. 14 Apr, 2010 1 commit
    • Shiyong Li's avatar
      slab: Fix missing DEBUG_SLAB last user · 5c5e3b33
      Shiyong Li authored
      Even with SLAB_RED_ZONE and SLAB_STORE_USER enabled, kernel would NOT store
      redzone and last user data around allocated memory space if "arch cache line >
      sizeof(unsigned long long)". As a result, last user information is unexpectedly
      MISSED while dumping slab corruption log.
      
      This fix makes sure that redzone and last user tags get stored unless the
      required alignment breaks redzone's.
      Signed-off-by: default avatarShiyong Li <shi-yong.li@motorola.com>
      Signed-off-by: default avatarPekka Enberg <penberg@cs.helsinki.fi>
      5c5e3b33
  10. 09 Apr, 2010 1 commit
    • Pekka Enberg's avatar
      slab: Generify kernel pointer validation · fc1c1833
      Pekka Enberg authored
      As suggested by Linus, introduce a kern_ptr_validate() helper that does some
      sanity checks to make sure a pointer is a valid kernel pointer.  This is a
      preparational step for fixing SLUB kmem_ptr_validate().
      
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Christoph Lameter <cl@linux-foundation.org>
      Cc: David Rientjes <rientjes@google.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Matt Mackall <mpm@selenic.com>
      Cc: Nick Piggin <npiggin@suse.de>
      Signed-off-by: default avatarPekka Enberg <penberg@cs.helsinki.fi>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      fc1c1833
  11. 07 Apr, 2010 1 commit
    • David Rientjes's avatar
      slab: add memory hotplug support · 8f9f8d9e
      David Rientjes authored
      Slab lacks any memory hotplug support for nodes that are hotplugged
      without cpus being hotplugged.  This is possible at least on x86
      CONFIG_MEMORY_HOTPLUG_SPARSE kernels where SRAT entries are marked
      ACPI_SRAT_MEM_HOT_PLUGGABLE and the regions of RAM represent a seperate
      node.  It can also be done manually by writing the start address to
      /sys/devices/system/memory/probe for kernels that have
      CONFIG_ARCH_MEMORY_PROBE set, which is how this patch was tested, and
      then onlining the new memory region.
      
      When a node is hotadded, a nodelist for that node is allocated and
      initialized for each slab cache.  If this isn't completed due to a lack
      of memory, the hotadd is aborted: we have a reasonable expectation that
      kmalloc_node(nid) will work for all caches if nid is online and memory is
      available.
      
      Since nodelists must be allocated and initialized prior to the new node's
      memory actually being online, the struct kmem_list3 is allocated off-node
      due to kmalloc_node()'s fallback.
      
      When an entire node would be offlined, its nodelists are subsequently
      drained.  If slab objects still exist and cannot be freed, the offline is
      aborted.  It is possible that objects will be allocated between this
      drain and page isolation, so it's still possible that the offline will
      still fail, however.
      Acked-by: default avatarChristoph Lameter <cl@linux-foundation.org>
      Signed-off-by: default avatarDavid Rientjes <rientjes@google.com>
      Signed-off-by: default avatarPekka Enberg <penberg@cs.helsinki.fi>
      8f9f8d9e
  12. 28 Mar, 2010 1 commit
  13. 26 Feb, 2010 1 commit
  14. 30 Jan, 2010 1 commit
    • Nick Piggin's avatar
      slab: fix regression in touched logic · 44b57f1c
      Nick Piggin authored
      When factoring common code into transfer_objects in commit 3ded175a ("slab: add
      transfer_objects() function"), the 'touched' logic got a bit broken. When
      refilling from the shared array (taking objects from the shared array), we are
      making use of the shared array so it should be marked as touched.
      
      Subsequently pulling an element from the cpu array and allocating it should
      also touch the cpu array, but that is taken care of after the alloc_done label.
      (So yes, the cpu array was getting touched = 1 twice).
      
      So revert this logic to how it worked in earlier kernels.
      
      This also affects the behaviour in __drain_alien_cache, which would previously
      'touch' the shared array and now does not. I think it is more logical not to
      touch there, because we are pushing objects into the shared array rather than
      pulling them off. So there is no good reason to postpone reaping them -- if the
      shared array is getting utilized, then it will get 'touched' in the alloc path
      (where this patch now restores the touch).
      Acked-by: default avatarChristoph Lameter <cl@linux-foundation.org>
      Signed-off-by: default avatarNick Piggin <npiggin@suse.de>
      Signed-off-by: default avatarPekka Enberg <penberg@cs.helsinki.fi>
      44b57f1c
  15. 11 Jan, 2010 1 commit
  16. 28 Dec, 2009 1 commit
  17. 17 Dec, 2009 1 commit
  18. 11 Dec, 2009 2 commits
    • Li Zefan's avatar
      tracing, slab: Fix no callsite ifndef CONFIG_KMEMTRACE · 0bb38a5c
      Li Zefan authored
      For slab, if CONFIG_KMEMTRACE and CONFIG_DEBUG_SLAB are not set,
      __do_kmalloc() will not track callers:
      
       # ./perf record -f -a -R -e kmem:kmalloc
       ^C
       # ./perf trace
       ...
                perf-2204  [000]   147.376774: kmalloc: call_site=c0529d2d ...
                perf-2204  [000]   147.400997: kmalloc: call_site=c0529d2d ...
                Xorg-1461  [001]   147.405413: kmalloc: call_site=0 ...
                Xorg-1461  [001]   147.405609: kmalloc: call_site=0 ...
             konsole-1776  [001]   147.405786: kmalloc: call_site=0 ...
      Signed-off-by: default avatarLi Zefan <lizf@cn.fujitsu.com>
      Reviewed-by: default avatarPekka Enberg <penberg@cs.helsinki.fi>
      Cc: Christoph Lameter <cl@linux-foundation.org>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: linux-mm@kvack.org <linux-mm@kvack.org>
      Cc: Eduard - Gabriel Munteanu <eduard.munteanu@linux360.ro>
      LKML-Reference: <4B21F8AE.6020804@cn.fujitsu.com>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      0bb38a5c
    • Li Zefan's avatar
      tracing, slab: Define kmem_cache_alloc_notrace ifdef CONFIG_TRACING · 0f24f128
      Li Zefan authored
      Define kmem_trace_alloc_{,node}_notrace() if CONFIG_TRACING is
      enabled, otherwise perf-kmem will show wrong stats ifndef
      CONFIG_KMEM_TRACE, because a kmalloc() memory allocation may
      be traced by both trace_kmalloc() and trace_kmem_cache_alloc().
      Signed-off-by: default avatarLi Zefan <lizf@cn.fujitsu.com>
      Reviewed-by: default avatarPekka Enberg <penberg@cs.helsinki.fi>
      Cc: Christoph Lameter <cl@linux-foundation.org>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: linux-mm@kvack.org <linux-mm@kvack.org>
      Cc: Eduard - Gabriel Munteanu <eduard.munteanu@linux360.ro>
      LKML-Reference: <4B21F89A.7000801@cn.fujitsu.com>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      0f24f128
  19. 06 Dec, 2009 3 commits
  20. 30 Nov, 2009 1 commit
    • Pekka Enberg's avatar
      SLAB: Fix lockdep annotations for CPU hotplug · ce79ddc8
      Pekka Enberg authored
      As reported by Paul McKenney:
      
        I am seeing some lockdep complaints in rcutorture runs that include
        frequent CPU-hotplug operations.  The tests are otherwise successful.
        My first thought was to send a patch that gave each array_cache
        structure's ->lock field its own struct lock_class_key, but you already
        have a init_lock_keys() that seems to be intended to deal with this.
      
        ------------------------------------------------------------------------
      
        =============================================
        [ INFO: possible recursive locking detected ]
        2.6.32-rc4-autokern1 #1
        ---------------------------------------------
        syslogd/2908 is trying to acquire lock:
         (&nc->lock){..-...}, at: [<c0000000001407f4>] .kmem_cache_free+0x118/0x2d4
      
        but task is already holding lock:
         (&nc->lock){..-...}, at: [<c0000000001411bc>] .kfree+0x1f0/0x324
      
        other info that might help us debug this:
        3 locks held by syslogd/2908:
         #0:  (&u->readlock){+.+.+.}, at: [<c0000000004556f8>] .unix_dgram_recvmsg+0x70/0x338
         #1:  (&nc->lock){..-...}, at: [<c0000000001411bc>] .kfree+0x1f0/0x324
         #2:  (&parent->list_lock){-.-...}, at: [<c000000000140f64>] .__drain_alien_cache+0x50/0xb8
      
        stack backtrace:
        Call Trace:
        [c0000000e8ccafc0] [c0000000000101e4] .show_stack+0x70/0x184 (unreliable)
        [c0000000e8ccb070] [c0000000000afebc] .validate_chain+0x6ec/0xf58
        [c0000000e8ccb180] [c0000000000b0ff0] .__lock_acquire+0x8c8/0x974
        [c0000000e8ccb280] [c0000000000b2290] .lock_acquire+0x140/0x18c
        [c0000000e8ccb350] [c000000000468df0] ._spin_lock+0x48/0x70
        [c0000000e8ccb3e0] [c0000000001407f4] .kmem_cache_free+0x118/0x2d4
        [c0000000e8ccb4a0] [c000000000140b90] .free_block+0x130/0x1a8
        [c0000000e8ccb540] [c000000000140f94] .__drain_alien_cache+0x80/0xb8
        [c0000000e8ccb5e0] [c0000000001411e0] .kfree+0x214/0x324
        [c0000000e8ccb6a0] [c0000000003ca860] .skb_release_data+0xe8/0x104
        [c0000000e8ccb730] [c0000000003ca2ec] .__kfree_skb+0x20/0xd4
        [c0000000e8ccb7b0] [c0000000003cf2c8] .skb_free_datagram+0x1c/0x5c
        [c0000000e8ccb830] [c00000000045597c] .unix_dgram_recvmsg+0x2f4/0x338
        [c0000000e8ccb920] [c0000000003c0f14] .sock_recvmsg+0xf4/0x13c
        [c0000000e8ccbb30] [c0000000003c28ec] .SyS_recvfrom+0xb4/0x130
        [c0000000e8ccbcb0] [c0000000003bfb78] .sys_recv+0x18/0x2c
        [c0000000e8ccbd20] [c0000000003ed388] .compat_sys_recv+0x14/0x28
        [c0000000e8ccbd90] [c0000000003ee1bc] .compat_sys_socketcall+0x178/0x220
        [c0000000e8ccbe30] [c0000000000085d4] syscall_exit+0x0/0x40
      
      This patch fixes the issue by setting up lockdep annotations during CPU
      hotplug.
      Reported-by: default avatarPaul E. McKenney <paulmck@linux.vnet.ibm.com>
      Tested-by: default avatarPaul E. McKenney <paulmck@linux.vnet.ibm.com>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Christoph Lameter <cl@linux-foundation.org>
      Signed-off-by: default avatarPekka Enberg <penberg@cs.helsinki.fi>
      ce79ddc8
  21. 29 Oct, 2009 1 commit
    • Tejun Heo's avatar
      percpu: make percpu symbols under kernel/ and mm/ unique · 1871e52c
      Tejun Heo authored
      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: default avatarTejun Heo <tj@kernel.org>
      Acked-by: default avatar(slab/vmstat) Christoph Lameter <cl@linux-foundation.org>
      Reviewed-by: default avatarChristoph 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
  22. 28 Oct, 2009 2 commits
  23. 22 Sep, 2009 1 commit
  24. 29 Jun, 2009 1 commit
    • Pekka Enberg's avatar
      SLAB: Fix lockdep annotations · ec5a36f9
      Pekka Enberg authored
      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: default avatarVenkatesh Pallipadi <venkatesh.pallipadi@intel.com>
      Signed-off-by: default avatarPekka Enberg <penberg@cs.helsinki.fi>
      ec5a36f9
  25. 26 Jun, 2009 1 commit
  26. 18 Jun, 2009 1 commit
  27. 17 Jun, 2009 2 commits
  28. 15 Jun, 2009 2 commits
  29. 13 Jun, 2009 1 commit
  30. 12 Jun, 2009 3 commits
    • Pekka Enberg's avatar
      slab: setup cpu caches later on when interrupts are enabled · 8429db5c
      Pekka Enberg authored
      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: default avatarPekka Enberg <penberg@cs.helsinki.fi>
      8429db5c
    • Pekka Enberg's avatar
      slab,slub: don't enable interrupts during early boot · 7e85ee0c
      Pekka Enberg authored
      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: default avatarPekka Enberg <penberg@cs.helsinki.fi>
      7e85ee0c
    • Pekka Enberg's avatar
      slab: fix gfp flag in setup_cpu_cache() · eb91f1d0
      Pekka Enberg authored
      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: default avatarPekka Enberg <penberg@cs.helsinki.fi>
      eb91f1d0