1. 17 10月, 2008 4 次提交
    • 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
    • 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. 27 7月, 2008 1 次提交
  3. 22 7月, 2008 2 次提交
  4. 15 5月, 2008 1 次提交
  5. 01 5月, 2008 1 次提交
    • B
      sysfs: Disallow truncation of files in sysfs · 40a2159a
      Ben Hutchings 提交于
      sysfs allows attribute files to be truncated, e.g. using ftruncate(), with the
      expected effect on their inode.   For most attributes, this doesn't change the
      "real" size of the file i.e. how much can be read from it.  However, the
      parameter validation for reading and writing binary attribute files is based
      on the inode size and not the size specified in the file's bin_attribute, so it
      can be broken by this. For example, if we try using dd to write to such a file:
      
      # pwd
      /sys/bus/pci/devices/0000:08:00.0
      # ls -l config
      -rw-r--r--  1 root root 4096 Feb  1 17:35 config
      # dd if=/dev/zero of=config bs=4 count=1
      1+0 records in
      1+0 records out
      # ls -l config
      -rw-r--r--  1 root root 0 Feb  1 17:50 config
      # dd if=/dev/zero of=config bs=4 count=1 seek=128
      dd: writing `config': No space left on device
      1+0 records in
      0+0 records out
      
      Also, after truncation to 0, parameter validation for read and write is
      disabled.  Most bin_attribute read and write methods also validate the size and
      offset, but for some this will allow out-of-range access.  This may be a
      security issue, though access to such files is often limited to root.  In any
      case, the validation should remain for safety's sake!)
      
      This was previously reported in Bugzilla as bug 9867.
      
      sysfs should ignore size changes or else refuse them (by returning -EINVAL).
      This patch makes it ignore them.
      Signed-off-by: NBen Hutchings <bhutchings@solarflare.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      40a2159a
  6. 30 4月, 2008 2 次提交
  7. 23 4月, 2008 1 次提交
  8. 20 4月, 2008 2 次提交
  9. 18 4月, 2008 1 次提交
  10. 25 3月, 2008 1 次提交
  11. 08 2月, 2008 1 次提交
  12. 25 1月, 2008 5 次提交
  13. 24 1月, 2008 2 次提交
  14. 17 1月, 2008 2 次提交
  15. 29 11月, 2007 1 次提交
    • M
      sysfs: fix off-by-one error in fill_read_buffer() · 8118a859
      Miao Xie 提交于
      I found that there is a off-by-one problem in the following code.
      
      Version:	2.6.24-rc2
      File:		fs/sysfs/file.c:118-122
      Function:	fill_read_buffer
      --------------------------------------------------------------------
      	count = ops->show(kobj, attr_sd->s_attr.attr, buffer->page);
      
      	sysfs_put_active_two(attr_sd);
      
      	BUG_ON(count > (ssize_t)PAGE_SIZE);
      --------------------------------------------------------------------
      
      Because according to the specification of the sysfs and the implement of
      the show methods, the show methods return the number of bytes which would
      be generated for the given input, excluding the trailing null.So if the
      return value of the show methods equals PAGE_SIZE - 1, the buffer is full
      in fact.  And if the return value equals PAGE_SIZE, the resulting string
      was already truncated,or buffer overflow occurred.
      
      This patch fixes an off-by-one error in fill_read_buffer.
      Signed-off-by: NMiao Xie <miaox@cn.fujitsu.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Acked-by: NTejun Heo <teheo@suse.de>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      8118a859
  16. 31 10月, 2007 1 次提交
  17. 20 10月, 2007 1 次提交
  18. 17 10月, 2007 4 次提交
  19. 13 10月, 2007 7 次提交