Skip to content
Snippets Groups Projects
  1. Aug 10, 2011
    • Marcin Slusarz's avatar
      debugobjects: Fix boot crash when kmemleak and debugobjects enabled · 308e3093
      Marcin Slusarz authored
      BugLink: http://bugs.launchpad.net/bugs/810425
      
      
      
      commit 161b6ae0e067e421b20bb35caf66bdb405c929ac upstream.
      
      Order of initialization look like this:
      ...
      debugobjects
      kmemleak
      ...(lots of other subsystems)...
      workqueues (through early initcall)
      ...
      
      debugobjects use schedule_work for batch freeing of its data and kmemleak
      heavily use debugobjects, so when it comes to freeing and workqueues were
      not initialized yet, kernel crashes:
      
      BUG: unable to handle kernel NULL pointer dereference at           (null)
      IP: [<ffffffff810854d1>] __queue_work+0x29/0x41a
       [<ffffffff81085910>] queue_work_on+0x16/0x1d
       [<ffffffff81085abc>] queue_work+0x29/0x55
       [<ffffffff81085afb>] schedule_work+0x13/0x15
       [<ffffffff81242de1>] free_object+0x90/0x95
       [<ffffffff81242f6d>] debug_check_no_obj_freed+0x187/0x1d3
       [<ffffffff814b6504>] ? _raw_spin_unlock_irqrestore+0x30/0x4d
       [<ffffffff8110bd14>] ? free_object_rcu+0x68/0x6d
       [<ffffffff8110890c>] kmem_cache_free+0x64/0x12c
       [<ffffffff8110bd14>] free_object_rcu+0x68/0x6d
       [<ffffffff810b58bc>] __rcu_process_callbacks+0x1b6/0x2d9
      ...
      
      because system_wq is NULL.
      
      Fix it by checking if workqueues susbystem was initialized before using.
      
      Signed-off-by: default avatarMarcin Slusarz <marcin.slusarz@gmail.com>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Tejun Heo <tj@kernel.org>
      Cc: Dipankar Sarma <dipankar@in.ibm.com>
      Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
      Link: http://lkml.kernel.org/r/20110528112342.GA3068@joi.lan
      
      
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      Signed-off-by: default avatarStefan Bader <stefan.bader@canonical.com>
      Signed-off-by: default avatarTim Gardner <tim.gardner@canonical.com>
      308e3093
    • Frederic Weisbecker's avatar
      rcu: Fix unpaired rcu_irq_enter() from locking selftests · ecd8d13e
      Frederic Weisbecker authored
      BugLink: http://bugs.launchpad.net/bugs/802383
      
      
      
      commit ba9f207c9f82115aba4ce04b22e0081af0ae300f upstream.
      
      HARDIRQ_ENTER() maps to irq_enter() which calls rcu_irq_enter().
      But HARDIRQ_EXIT() maps to __irq_exit() which doesn't call
      rcu_irq_exit().
      
      So for every locking selftest that simulates hardirq disabled,
      we create an imbalance in the rcu extended quiescent state
      internal state.
      
      As a result, after the first missing rcu_irq_exit(), subsequent
      irqs won't exit dyntick-idle mode after leaving the interrupt
      handler.  This means that RCU won't see the affected CPU as being
      in an extended quiescent state, resulting in long grace-period
      delays (as in grace periods extending for hours).
      
      To fix this, just use __irq_enter() to simulate the hardirq
      context. This is sufficient for the locking selftests as we
      don't need to exit any extended quiescent state or perform
      any check that irqs normally do when they wake up from idle.
      
      As a side effect, this patch makes it possible to restore
      "rcu: Decrease memory-barrier usage based on semi-formal proof",
      which eventually helped finding this bug.
      
      Reported-and-tested-by: default avatarYinghai Lu <yinghai@kernel.org>
      Signed-off-by: default avatarFrederic Weisbecker <fweisbec@gmail.com>
      Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Signed-off-by: default avatarPaul E. McKenney <paulmck@linux.vnet.ibm.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      Signed-off-by: default avatarTim Gardner <tim.gardner@canonical.com>
      ecd8d13e
  2. Mar 14, 2011
  3. Jan 05, 2011
    • Masanori ITOH's avatar
      percpu: fix list_head init bug in __percpu_counter_init() · c35acee3
      Masanori ITOH authored
      BugLink: http://bugs.launchpad.net/bugs/688669
      
      
      
      commit 8474b591faf3bb0a1e08a60d21d6baac498f15e4 upstream.
      
      WARNING: at lib/list_debug.c:26 __list_add+0x3f/0x81()
      Hardware name: Express5800/B120a [N8400-085]
      list_add corruption. next->prev should be prev (ffffffff81a7ea00), but was dead000000200200. (next=ffff88080b872d58).
      Modules linked in: aoe ipt_MASQUERADE iptable_nat nf_nat autofs4 sunrpc bridge 8021q garp stp llc ipv6 cpufreq_ondemand acpi_cpufreq freq_table dm_round_robin dm_multipath kvm_intel kvm uinput lpfc scsi_transport_fc igb ioatdma scsi_tgt i2c_i801 i2c_core dca iTCO_wdt iTCO_vendor_support pcspkr shpchp megaraid_sas [last unloaded: aoe]
      Pid: 54, comm: events/3 Tainted: G        W  2.6.34-vanilla1 #1
      Call Trace:
      [<ffffffff8104bd77>] warn_slowpath_common+0x7c/0x94
      [<ffffffff8104bde6>] warn_slowpath_fmt+0x41/0x43
      [<ffffffff8120fd2e>] __list_add+0x3f/0x81
      [<ffffffff81212a12>] __percpu_counter_init+0x59/0x6b
      [<ffffffff810d8499>] bdi_init+0x118/0x17e
      [<ffffffff811f2c50>] blk_alloc_queue_node+0x79/0x143
      [<ffffffff811f2d2b>] blk_alloc_queue+0x11/0x13
      [<ffffffffa02a931d>] aoeblk_gdalloc+0x8e/0x1c9 [aoe]
      [<ffffffffa02aa655>] aoecmd_sleepwork+0x25/0xa8 [aoe]
      [<ffffffff8106186c>] worker_thread+0x1a9/0x237
      [<ffffffffa02aa630>] ? aoecmd_sleepwork+0x0/0xa8 [aoe]
      [<ffffffff81065827>] ? autoremove_wake_function+0x0/0x39
      [<ffffffff810616c3>] ? worker_thread+0x0/0x237
      [<ffffffff810653ad>] kthread+0x7f/0x87
      [<ffffffff8100aa24>] kernel_thread_helper+0x4/0x10
      [<ffffffff8106532e>] ? kthread+0x0/0x87
      [<ffffffff8100aa20>] ? kernel_thread_helper+0x0/0x10
      
      It's because there is no initialization code for a list_head contained in
      the struct backing_dev_info under CONFIG_HOTPLUG_CPU, and the bug comes up
      when block device drivers calling blk_alloc_queue() are used.  In case of
      me, I got them by using aoe.
      
      Signed-off-by: default avatarMasanori Itoh <itoumsn@nttdata.co.jp>
      Cc: Tejun Heo <tj@kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      Signed-off-by: default avatarStefan Bader <stefan.bader@canonical.com>
      Signed-off-by: default avatarBrad Figg <brad.figg@canonical.com>
      c35acee3
  4. Jun 02, 2010
  5. Apr 08, 2010
  6. Mar 17, 2010
  7. Mar 05, 2010
  8. Jan 19, 2010
  9. Jan 08, 2010
  10. Nov 19, 2009
    • David Howells's avatar
      FS-Cache: Don't delete pending pages from the page-store tracking tree · 285e728b
      David Howells authored
      
      Don't delete pending pages from the page-store tracking tree, but rather send
      them for another write as they've presumably been updated.
      
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      285e728b
    • David Howells's avatar
      FS-Cache: Use radix tree preload correctly in tracking of pages to be stored · b34df792
      David Howells authored
      
      __fscache_write_page() attempts to load the radix tree preallocation pool for
      the CPU it is on before calling radix_tree_insert(), as the insertion must be
      done inside a pair of spinlocks.
      
      Use of the preallocation pool, however, is contingent on the radix tree being
      initialised without __GFP_WAIT specified.  __fscache_acquire_cookie() was
      passing GFP_NOFS to INIT_RADIX_TREE() - but that includes __GFP_WAIT.
      
      The solution is to AND out __GFP_WAIT.
      
      Additionally, the banner comment to radix_tree_preload() is altered to make
      note of this prerequisite.  Possibly there should be a WARN_ON() too.
      
      Without this fix, I have seen the following recursive deadlock caused by
      radix_tree_insert() attempting to allocate memory inside the spinlocked
      region, which resulted in FS-Cache being called back into to release memory -
      which required the spinlock already held.
      
      =============================================
      [ INFO: possible recursive locking detected ]
      2.6.32-rc6-cachefs #24
      ---------------------------------------------
      nfsiod/7916 is trying to acquire lock:
       (&cookie->lock){+.+.-.}, at: [<ffffffffa0076872>] __fscache_uncache_page+0xdb/0x160 [fscache]
      
      but task is already holding lock:
       (&cookie->lock){+.+.-.}, at: [<ffffffffa0076acc>] __fscache_write_page+0x15c/0x3f3 [fscache]
      
      other info that might help us debug this:
      5 locks held by nfsiod/7916:
       #0:  (nfsiod){+.+.+.}, at: [<ffffffff81048290>] worker_thread+0x19a/0x2e2
       #1:  (&task->u.tk_work#2){+.+.+.}, at: [<ffffffff81048290>] worker_thread+0x19a/0x2e2
       #2:  (&cookie->lock){+.+.-.}, at: [<ffffffffa0076acc>] __fscache_write_page+0x15c/0x3f3 [fscache]
       #3:  (&object->lock#2){+.+.-.}, at: [<ffffffffa0076b07>] __fscache_write_page+0x197/0x3f3 [fscache]
       #4:  (&cookie->stores_lock){+.+...}, at: [<ffffffffa0076b0f>] __fscache_write_page+0x19f/0x3f3 [fscache]
      
      stack backtrace:
      Pid: 7916, comm: nfsiod Not tainted 2.6.32-rc6-cachefs #24
      Call Trace:
       [<ffffffff8105ac7f>] __lock_acquire+0x1649/0x16e3
       [<ffffffff81059ded>] ? __lock_acquire+0x7b7/0x16e3
       [<ffffffff8100e27d>] ? dump_trace+0x248/0x257
       [<ffffffff8105ad70>] lock_acquire+0x57/0x6d
       [<ffffffffa0076872>] ? __fscache_uncache_page+0xdb/0x160 [fscache]
       [<ffffffff8135467c>] _spin_lock+0x2c/0x3b
       [<ffffffffa0076872>] ? __fscache_uncache_page+0xdb/0x160 [fscache]
       [<ffffffffa0076872>] __fscache_uncache_page+0xdb/0x160 [fscache]
       [<ffffffffa0077eb7>] ? __fscache_check_page_write+0x0/0x71 [fscache]
       [<ffffffffa00b4755>] nfs_fscache_release_page+0x86/0xc4 [nfs]
       [<ffffffffa00907f0>] nfs_release_page+0x3c/0x41 [nfs]
       [<ffffffff81087ffb>] try_to_release_page+0x32/0x3b
       [<ffffffff81092c2b>] shrink_page_list+0x316/0x4ac
       [<ffffffff81058a9b>] ? mark_held_locks+0x52/0x70
       [<ffffffff8135451b>] ? _spin_unlock_irq+0x2b/0x31
       [<ffffffff81093153>] shrink_inactive_list+0x392/0x67c
       [<ffffffff81058a9b>] ? mark_held_locks+0x52/0x70
       [<ffffffff810934ca>] shrink_list+0x8d/0x8f
       [<ffffffff81093744>] shrink_zone+0x278/0x33c
       [<ffffffff81052c70>] ? ktime_get_ts+0xad/0xba
       [<ffffffff8109453b>] try_to_free_pages+0x22e/0x392
       [<ffffffff8109184c>] ? isolate_pages_global+0x0/0x212
       [<ffffffff8108e16b>] __alloc_pages_nodemask+0x3dc/0x5cf
       [<ffffffff810ae24a>] cache_alloc_refill+0x34d/0x6c1
       [<ffffffff811bcf74>] ? radix_tree_node_alloc+0x52/0x5c
       [<ffffffff810ae929>] kmem_cache_alloc+0xb2/0x118
       [<ffffffff811bcf74>] radix_tree_node_alloc+0x52/0x5c
       [<ffffffff811bcfd5>] radix_tree_insert+0x57/0x19c
       [<ffffffffa0076b53>] __fscache_write_page+0x1e3/0x3f3 [fscache]
       [<ffffffffa00b4248>] __nfs_readpage_to_fscache+0x58/0x11e [nfs]
       [<ffffffffa009bb77>] nfs_readpage_release+0x34/0x9b [nfs]
       [<ffffffffa009c0d9>] nfs_readpage_release_full+0x32/0x4b [nfs]
       [<ffffffffa0006cff>] rpc_release_calldata+0x12/0x14 [sunrpc]
       [<ffffffffa0006e2d>] rpc_free_task+0x59/0x61 [sunrpc]
       [<ffffffffa0006f03>] rpc_async_release+0x10/0x12 [sunrpc]
       [<ffffffff810482e5>] worker_thread+0x1ef/0x2e2
       [<ffffffff81048290>] ? worker_thread+0x19a/0x2e2
       [<ffffffff81352433>] ? thread_return+0x3e/0x101
       [<ffffffffa0006ef3>] ? rpc_async_release+0x0/0x12 [sunrpc]
       [<ffffffff8104bff5>] ? autoremove_wake_function+0x0/0x34
       [<ffffffff81058d25>] ? trace_hardirqs_on+0xd/0xf
       [<ffffffff810480f6>] ? worker_thread+0x0/0x2e2
       [<ffffffff8104bd21>] kthread+0x7a/0x82
       [<ffffffff8100beda>] child_rip+0xa/0x20
       [<ffffffff8100b87c>] ? restore_args+0x0/0x30
       [<ffffffff8104c2b9>] ? add_wait_queue+0x15/0x44
       [<ffffffff8104bca7>] ? kthread+0x0/0x82
       [<ffffffff8100bed0>] ? child_rip+0x0/0x20
      
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      b34df792
    • Linus Torvalds's avatar
      strcmp: fix overflow and possibly signedness error · a414f01a
      Linus Torvalds authored
      
      Doing the strcmp return value as
      
      	signed char __res = *cs - *ct;
      
      is wrong for two reasons.  The subtraction can overflow because __res
      doesn't use a type big enough.  Moreover the compared bytes should be
      interpreted as unsigned char as specified by POSIX.
      
      The same problem is fixed in strncmp.
      
      Signed-off-by: default avatarUwe Kleine-König <u.kleine-koenig@pengutronix.de>
      Cc: Michael Buesch <mb@bu3sch.de>
      Cc: Andreas Schwab <schwab@linux-m68k.org>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      a414f01a
  11. Oct 29, 2009
  12. Oct 27, 2009
  13. Oct 11, 2009
  14. Oct 06, 2009
  15. Oct 02, 2009
  16. Sep 24, 2009
  17. Sep 22, 2009
  18. Sep 21, 2009
  19. Sep 20, 2009
  20. Sep 17, 2009
    • Steven Rostedt's avatar
      vsnprintf: remove duplicate comment of vsnprintf · 0efb4d20
      Steven Rostedt authored
      
      Remove the duplicate comment of bstr_printf that is the same as the
      vsnprintf.
      
      Add the 's' option to the comment for the pointer function. This is
      more of an internal function so the little duplication of the comment
      here is OK.
      
      Reported-by: default avatarZhaolei <zhaolei@cn.fujitsu.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarSteven Rostedt <rostedt@goodmis.org>
      0efb4d20
    • Steven Rostedt's avatar
      vsprintf: add %ps that is the same as %pS but is like %pf · 91adcd2c
      Steven Rostedt authored
      
      On PowerPC64 function pointers do not point directly at the functions,
      but instead point to pointers to the functions. The output of %pF expects
      to point to a pointer to the function, whereas %pS will show the function
      itself.
      
      mcount returns the direct pointer to the function and not the pointer to
      the pointer. Thus %pS must be used to show this. The function tracer
      requires printing of the functions without offsets and uses the %pf
      instead.
      
       %pF produces run_local_timers+0x4/0x1f
       %pf produces just run_local_timers
      
      For PowerPC64, we need to use the direct pointer, and we only have
      %pS which will produce .run_local_timers+0x4/0x1f
      
      This patch creates a %ps that matches the %pf as %pS matches %pF.
      
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Zhao Lei <zhaolei@cn.fujitsu.com>
      Acked-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
      Signed-off-by: default avatarSteven Rostedt <rostedt@goodmis.org>
      91adcd2c
  21. Sep 15, 2009
  22. Sep 02, 2009
    • David Howells's avatar
      CRED: Add some configurable debugging [try #6] · e0e81739
      David Howells authored
      Add a config option (CONFIG_DEBUG_CREDENTIALS) to turn on some debug checking
      for credential management.  The additional code keeps track of the number of
      pointers from task_structs to any given cred struct, and checks to see that
      this number never exceeds the usage count of the cred struct (which includes
      all references, not just those from task_structs).
      
      Furthermore, if SELinux is enabled, the code also checks that the security
      pointer in the cred struct is never seen to be invalid.
      
      This attempts to catch the bug whereby inode_has_perm() faults in an nfsd
      kernel thread on seeing cred->security be a NULL pointer (it appears that the
      credential struct has been previously released):
      
      	http://www.kerneloops.org/oops.php?number=252883
      
      
      
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Signed-off-by: default avatarJames Morris <jmorris@namei.org>
      e0e81739
  23. Aug 29, 2009
  24. Aug 27, 2009
Loading