1. 17 10月, 2008 5 次提交
    • T
      sysfs: use ilookup5() instead of ilookup5_nowait() · 45c076c5
      Tejun Heo 提交于
      As inode creation is protected by sysfs_mutex, ilookup5_nowait()
      always either fails to find at all or finds one which is fully
      initialized, so using ilookup5_nowait() or ilookup5() doesn't make any
      difference.  Switch to ilookup5() as it's planned to be removed.  This
      change also makes lookup return value handling a bit simpler.
      
      This change was suggested by Al Viro.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Cc: Al Viro <viro@hera.kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      45c076c5
    • N
      sysfs: fix deadlock · b31ca3f5
      Nick Piggin 提交于
      On Thu, Sep 11, 2008 at 10:27:10AM +0200, Ingo Molnar wrote:
      
      > and it's working fine on most boxes. One testbox found this new locking
      > scenario:
      >
      > PM: Adding info for No Bus:vcsa7
      > EDAC DEBUG: MC0: i82860_check()
      >
      > =======================================================
      > [ INFO: possible circular locking dependency detected ]
      > 2.6.27-rc6-tip #1
      > -------------------------------------------------------
      > X/4873 is trying to acquire lock:
      >  (&bb->mutex){--..}, at: [<c020ba20>] mmap+0x40/0xa0
      >
      > but task is already holding lock:
      >  (&mm->mmap_sem){----}, at: [<c0125a1e>] sys_mmap2+0x8e/0xc0
      >
      > which lock already depends on the new lock.
      >
      >
      > the existing dependency chain (in reverse order) is:
      >
      > -> #1 (&mm->mmap_sem){----}:
      >        [<c017dc96>] validate_chain+0xa96/0xf50
      >        [<c017ef2b>] __lock_acquire+0x2cb/0x5b0
      >        [<c017f299>] lock_acquire+0x89/0xc0
      >        [<c01aa8fb>] might_fault+0x6b/0x90
      >        [<c040b618>] copy_to_user+0x38/0x60
      >        [<c020bcfb>] read+0xfb/0x170
      >        [<c01c09a5>] vfs_read+0x95/0x110
      >        [<c01c1443>] sys_pread64+0x63/0x80
      >        [<c012146f>] sysenter_do_call+0x12/0x43
      >        [<ffffffff>] 0xffffffff
      >
      > -> #0 (&bb->mutex){--..}:
      >        [<c017d8b7>] validate_chain+0x6b7/0xf50
      >        [<c017ef2b>] __lock_acquire+0x2cb/0x5b0
      >        [<c017f299>] lock_acquire+0x89/0xc0
      >        [<c0d6f2ab>] __mutex_lock_common+0xab/0x3c0
      >        [<c0d6f698>] mutex_lock_nested+0x38/0x50
      >        [<c020ba20>] mmap+0x40/0xa0
      >        [<c01b111e>] mmap_region+0x14e/0x450
      >        [<c01b170f>] do_mmap_pgoff+0x2ef/0x310
      >        [<c0125a3d>] sys_mmap2+0xad/0xc0
      >        [<c012146f>] sysenter_do_call+0x12/0x43
      >        [<ffffffff>] 0xffffffff
      >
      > other info that might help us debug this:
      >
      > 1 lock held by X/4873:
      >  #0:  (&mm->mmap_sem){----}, at: [<c0125a1e>] sys_mmap2+0x8e/0xc0
      >
      > stack backtrace:
      > Pid: 4873, comm: X Not tainted 2.6.27-rc6-tip #1
      >  [<c017cd09>] print_circular_bug_tail+0x79/0xc0
      >  [<c017d8b7>] validate_chain+0x6b7/0xf50
      >  [<c017a5b5>] ? trace_hardirqs_off_caller+0x15/0xb0
      >  [<c017ef2b>] __lock_acquire+0x2cb/0x5b0
      >  [<c017f299>] lock_acquire+0x89/0xc0
      >  [<c020ba20>] ? mmap+0x40/0xa0
      >  [<c0d6f2ab>] __mutex_lock_common+0xab/0x3c0
      >  [<c020ba20>] ? mmap+0x40/0xa0
      >  [<c0d6f698>] mutex_lock_nested+0x38/0x50
      >  [<c020ba20>] ? mmap+0x40/0xa0
      >  [<c020ba20>] mmap+0x40/0xa0
      >  [<c01b111e>] mmap_region+0x14e/0x450
      >  [<c01afb88>] ? arch_get_unmapped_area_topdown+0xf8/0x160
      >  [<c01b170f>] do_mmap_pgoff+0x2ef/0x310
      >  [<c0125a3d>] sys_mmap2+0xad/0xc0
      >  [<c012146f>] sysenter_do_call+0x12/0x43
      >  [<c0120000>] ? __switch_to+0x130/0x220
      >  =======================
      > evbug.c: Event. Dev: input3, Type: 20, Code: 0, Value: 500
      > warning: `sudo' uses deprecated v2 capabilities in a way that may be insecure.
      >
      > i've attached the config.
      >
      > at first sight it looks like a genuine bug in fs/sysfs/bin.c?
      
      Yes, it is a real bug by the looks. bin.c takes bb->mutex under mmap_sem
      when it is mmapped, and then does its copy_*_user under bb->mutex too.
      
      Here is a basic fix for the sysfs lor.
      
      
      From: Nick Piggin <npiggin@suse.de>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      b31ca3f5
    • N
      sysfs: Support sysfs_notify from atomic context with new sysfs_notify_dirent · f1282c84
      Neil Brown 提交于
      Support sysfs_notify from atomic context with new sysfs_notify_dirent
      
      sysfs_notify currently takes sysfs_mutex.
      This means that it cannot be called in atomic context.
      sysfs_mutex  is sometimes held over a malloc (sysfs_rename_dir)
      so it can block on low memory.
      
      In md I want to be able to notify on a sysfs attribute from
      atomic context, and I don't want to block on low memory because I
      could be in the writeout path for freeing memory.
      
      So:
       - export the "sysfs_dirent" structure along with sysfs_get, sysfs_put
         and sysfs_get_dirent so I can get the sysfs_dirent that I want to
         notify on and hold it in an md structure.
       - split sysfs_notify_dirent out of sysfs_notify so the sysfs_dirent
         can be notified on with no blocking (just a spinlock).
      Signed-off-by: NNeil Brown <neilb@suse.de>
      Acked-by: NTejun Heo <tj@kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      f1282c84
    • G
      device create: misc: convert device_create_drvdata to device_create · a9b12619
      Greg Kroah-Hartman 提交于
      Now that device_create() has been audited, rename things back to the
      original call to be sane.
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      a9b12619
    • A
      sysfs: crash debugging · ae87221d
      Andrew Morton 提交于
      Print the name of the last-accessed sysfs file when we oops, to help track
      down oopses which occur in sysfs store/read handlers.  Because these oopses
      tend to not leave any trace of the offending code in the stack traces.
      
      Cc: Kay Sievers <kay.sievers@vrfy.org>
      Cc: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      ae87221d
  2. 16 10月, 2008 1 次提交
  3. 15 10月, 2008 7 次提交
  4. 14 10月, 2008 27 次提交
新手
引导
客服 返回
顶部