1. 11 9月, 2009 1 次提交
  2. 29 7月, 2009 1 次提交
    • P
      sysfs: fix hardlink count on device_move · 0f58b445
      Peter Oberparleiter 提交于
      Update directory hardlink count when moving kobjects to a new parent.
      Fixes the following problem which occurs when several devices are
      moved to the same parent and then unregistered:
      
      > ls -laF /sys/devices/css0/defunct/
      > total 0
      > drwxr-xr-x 4294967295 root root    0 2009-07-14 17:02 ./
      > drwxr-xr-x        114 root root    0 2009-07-14 17:02 ../
      > drwxr-xr-x          2 root root    0 2009-07-14 17:01 power/
      > -rw-r--r--          1 root root 4096 2009-07-14 17:01 uevent
      Signed-off-by: NPeter Oberparleiter <oberpar@linux.vnet.ibm.com>
      Cc: stable <stable@kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      0f58b445
  3. 09 7月, 2009 1 次提交
  4. 16 6月, 2009 1 次提交
  5. 29 5月, 2009 1 次提交
  6. 21 4月, 2009 1 次提交
  7. 17 4月, 2009 2 次提交
    • K
      sysfs: sysfs poll keep the poll rule of regular file. · 1af3557a
      KOSAKI Motohiro 提交于
      Currently, following test programs don't finished.
      
      % ruby -e '
      Thread.new { sleep }
      File.read("/sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies")
      '
      
      strace expose the reason.
      
      ...
      open("/sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies", O_RDONLY|O_LARGEFILE) = 3
      ioctl(3, SNDCTL_TMR_TIMEBASE or TCGETS, 0xbf9fa6b8) = -1 ENOTTY (Inappropriate ioctl for device)
      fstat64(3, {st_mode=S_IFREG|0444, st_size=4096, ...}) = 0
      _llseek(3, 0, [0], SEEK_CUR)            = 0
      select(4, [3], NULL, NULL, NULL)        = 1 (in [3])
      read(3, "1400000 1300000 1200000 1100000 1"..., 4096) = 62
      select(4, [3], NULL, NULL, NULL
      
      
      Because Ruby (the scripting language) VM assume select system-call
      against regular file don't block.  it because SUSv3 says "Regular files
      shall always poll TRUE for reading and writing".  see
      http://www.opengroup.org/onlinepubs/009695399/functions/poll.html it
      seems valid assumption.
      
      But sysfs_poll() don't keep this rule although sysfs file can read and
      write always.
      
      This patch restore proper poll behavior to sysfs.
      /sys/block/md*/md/sync_action polling application and another sysfs
      updating sensitive application still can use POLLERR and POLLPRI.
      
      Cc: Neil Brown <neilb@suse.de>
      Signed-off-by: NKOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      1af3557a
    • A
      sysfs: don't use global workqueue in sysfs_schedule_callback() · d110271e
      Alex Chiang 提交于
      A sysfs attribute using sysfs_schedule_callback() to commit suicide
      may end up calling device_unregister(), which will eventually call
      a driver's ->remove function.
      
      Drivers may call flush_scheduled_work() in their shutdown routines,
      in which case lockdep will complain with something like the following:
      
        =============================================
        [ INFO: possible recursive locking detected ]
        2.6.29-rc8-kk #1
        ---------------------------------------------
        events/4/56 is trying to acquire lock:
        (events){--..}, at: [<ffffffff80257fc0>] flush_workqueue+0x0/0xa0
      
        but task is already holding lock:
        (events){--..}, at: [<ffffffff80257648>] run_workqueue+0x108/0x230
      
        other info that might help us debug this:
        3 locks held by events/4/56:
        #0:  (events){--..}, at: [<ffffffff80257648>] run_workqueue+0x108/0x230
        #1:  (&ss->work){--..}, at: [<ffffffff80257648>] run_workqueue+0x108/0x230
        #2:  (pci_remove_rescan_mutex){--..}, at: [<ffffffff803c10d1>] remove_callback+0x21/0x40
      
        stack backtrace:
        Pid: 56, comm: events/4 Not tainted 2.6.29-rc8-kk #1
        Call Trace:
        [<ffffffff8026dfcd>] validate_chain+0xb7d/0x1260
        [<ffffffff8026eade>] __lock_acquire+0x42e/0xa40
        [<ffffffff8026f148>] lock_acquire+0x58/0x80
        [<ffffffff80257fc0>] ? flush_workqueue+0x0/0xa0
        [<ffffffff8025800d>] flush_workqueue+0x4d/0xa0
        [<ffffffff80257fc0>] ? flush_workqueue+0x0/0xa0
        [<ffffffff80258070>] flush_scheduled_work+0x10/0x20
        [<ffffffffa0144065>] e1000_remove+0x55/0xfe [e1000e]
        [<ffffffff8033ee30>] ? sysfs_schedule_callback_work+0x0/0x50
        [<ffffffff803bfeb2>] pci_device_remove+0x32/0x70
        [<ffffffff80441da9>] __device_release_driver+0x59/0x90
        [<ffffffff80441edb>] device_release_driver+0x2b/0x40
        [<ffffffff804419d6>] bus_remove_device+0xa6/0x120
        [<ffffffff8043e46b>] device_del+0x12b/0x190
        [<ffffffff8043e4f6>] device_unregister+0x26/0x70
        [<ffffffff803ba969>] pci_stop_dev+0x49/0x60
        [<ffffffff803baab0>] pci_remove_bus_device+0x40/0xc0
        [<ffffffff803c10d9>] remove_callback+0x29/0x40
        [<ffffffff8033ee4f>] sysfs_schedule_callback_work+0x1f/0x50
        [<ffffffff8025769a>] run_workqueue+0x15a/0x230
        [<ffffffff80257648>] ? run_workqueue+0x108/0x230
        [<ffffffff8025846f>] worker_thread+0x9f/0x100
        [<ffffffff8025bce0>] ? autoremove_wake_function+0x0/0x40
        [<ffffffff802583d0>] ? worker_thread+0x0/0x100
        [<ffffffff8025b89d>] kthread+0x4d/0x80
        [<ffffffff8020d4ba>] child_rip+0xa/0x20
        [<ffffffff8020cebc>] ? restore_args+0x0/0x30
        [<ffffffff8025b850>] ? kthread+0x0/0x80
        [<ffffffff8020d4b0>] ? child_rip+0x0/0x20
      
      Although we know that the device_unregister path will never acquire
      a lock that a driver might try to acquire in its ->remove, in general
      we should never attempt to flush a workqueue from within the same
      workqueue, and lockdep rightly complains.
      
      So as long as sysfs attributes cannot commit suicide directly and we
      are stuck with this callback mechanism, put the sysfs callbacks on
      their own workqueue instead of the global one.
      
      This has the side benefit that if a suicidal sysfs attribute kicks
      off a long chain of ->remove callbacks, we no longer induce a long
      delay on the global queue.
      
      This also fixes a missing module_put in the error path introduced
      by sysfs-only-allow-one-scheduled-removal-callback-per-kobj.patch.
      
      We never destroy the workqueue, but I'm not sure that's a
      problem.
      Reported-by: NKenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
      Tested-by: NKenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
      Signed-off-by: NAlex Chiang <achiang@hp.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      d110271e
  8. 01 4月, 2009 1 次提交
  9. 28 3月, 2009 1 次提交
  10. 25 3月, 2009 7 次提交
    • H
      sysfs: fix some bin_vm_ops errors · 095160ae
      Hugh Dickins 提交于
      Commit 86c9508eb1c0ce5aa07b5cf1d36b60c54efc3d7a
      "sysfs: don't block indefinitely for unmapped files" in linux-next
      crashes the PowerMac G5 when X starts up.  It's caught out by the way
      powerpc's pci_mmap of legacy_mem uses shmem_zero_setup(), substituting
      a new vma->vm_file whose private_data no longer points to the bin_buffer
      (substitution done because some versions of X crash if that mmap fails).
      
      The fix to this is straightforward: the original vm_file is fput() in
      that case, so this mmap won't block sysfs at all, so just don't switch
      over to bin_vm_ops if vm_file has changed.
      
      But more fixes made before realizing that was the problem:-
      
      It should not be an error if bin_page_mkwrite() finds no underlying
      page_mkwrite().
      
      Check that a file already mmap'ed has the same underlying vm_ops
      _before_ pointing vma->vm_ops at bin_vm_ops.
      
      If the file being mmap'ed is a shmem/tmpfs file, don't fail the mmap
      on CONFIG_NUMA=y, just because that has a set_policy and get_policy:
      provide bin_set_policy, bin_get_policy and bin_migrate.
      Signed-off-by: NHugh Dickins <hugh@veritas.com>
      Acked-by: NEric Biederman <ebiederm@aristanetworks.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      
      095160ae
    • A
      sysfs: only allow one scheduled removal callback per kobj · 66942064
      Alex Chiang 提交于
      The only way for a sysfs attribute to remove itself (without
      deadlock) is to use the sysfs_schedule_callback() interface.
      
      Vegard Nossum discovered that a poorly written sysfs ->store
      callback can repeatedly schedule remove callbacks on the same
      device over and over, e.g.
      
      	$ while true ; do echo 1 > /sys/devices/.../remove ; done
      
      If the 'remove' attribute uses the sysfs_schedule_callback API
      and also does not protect itself from concurrent accesses, its
      callback handler will be called multiple times, and will
      eventually attempt to perform operations on a freed kobject,
      leading to many problems.
      
      Instead of requiring all callers of sysfs_schedule_callback to
      implement their own synchronization, provide the protection in
      the infrastructure.
      
      Now, sysfs_schedule_callback will only allow one scheduled
      callback per kobject. On subsequent calls with the same kobject,
      return -EAGAIN.
      
      This is a short term fix. The long term fix is to allow sysfs
      attributes to remove themselves directly, without any of this
      callback hokey pokey.
      
      [cornelia.huck@de.ibm.com: s390 ccwgroup bits]
      
      Reported-by: vegard.nossum@gmail.com
      Signed-off-by: NAlex Chiang <achiang@hp.com>
      Acked-by: NCornelia Huck <cornelia.huck@de.ibm.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      66942064
    • E
      sysfs: don't block indefinitely for unmapped files. · e0edd3c6
      Eric W. Biederman 提交于
      Modify sysfs bin files so that we can remove the bin file while they are
      still mapped.  When the kobject is removed we unmap the bin file and
      arrange for future accesses to the mapping to receive SIGBUS.
      
      Implementing this prevents a nasty DOS when pci devices are hot plugged
      and unplugged.  Where if any of their resources were mmaped the kernel
      could not free up their pci resources or release their pci data
      structures.
      
      [akpm@linux-foundation.org: remove unused var]
      Signed-off-by: NEric W. Biederman <ebiederm@aristanetworks.com>
      Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
      Acked-by: NTejun Heo <tj@kernel.org>
      Cc: Kay Sievers <kay.sievers@vrfy.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      e0edd3c6
    • E
      sysfs: reference sysfs_dirent from sysfs inodes · 04256b4a
      Eric W. Biederman 提交于
      The sysfs_dirent serves as both an inode and a directory entry
      for sysfs.  To prevent the sysfs inode numbers from being freed
      prematurely hold a reference to sysfs_dirent from the sysfs inode.
      
      [akpm@linux-foundation.org: add comment]
      Signed-off-by: NEric W. Biederman <ebiederm@aristanetworks.com>
      Cc: Tejun Heo <tj@kernel.org>
      Cc: Al Viro <viro@ZenIV.linux.org.uk>
      Cc: Cornelia Huck <cornelia.huck@de.ibm.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      04256b4a
    • A
      sysfs: sysfs_add_one WARNs with full path to duplicate filename · 425cb029
      Alex Chiang 提交于
      sysfs: sysfs_add_one WARNs with full path to duplicate filename
      
      As a debugging aid, it can be useful to know the full path to a
      duplicate file being created in sysfs.
      
      We now will display warnings such as:
      
      	sysfs: cannot create duplicate filename '/foo'
      
      when attempting to create multiple files named 'foo' in the sysfs
      root, or:
      
      	sysfs: cannot create duplicate filename '/bus/pci/slots/5/foo'
      
      when attempting to create multiple files named 'foo' under a
      given directory in sysfs.
      
      The path displayed is always a relative path to sysfs_root. The
      leading '/' in the path name refers to the sysfs_root mount
      point, and should not be confused with the "real" '/'.
      
      Thanks to Alex Williamson for essentially writing sysfs_pathname.
      
      Cc: Alex Williamson <alex.williamson@hp.com>
      Signed-off-by: NAlex Chiang <achiang@hp.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      425cb029
    • E
      sysfs: Take sysfs_mutex when fetching the root inode. · 4a67a1bc
      Eric W. Biederman 提交于
      sysfs_get_inode ultimately calls sysfs_count_nlink when the a
      directory inode is fectched.  sysfs_count_nlink needs to be
      called under the sysfs_mutex to guard against the unlikely
      but possible scenario that the root directory is changing
      as we are counting the number entries in it, and just in
      general to be consistent.
      Signed-off-by: NEric W. Biederman <ebiederm@aristanetworks.com>
      Acked-by: NTejun Heo <tj@kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      4a67a1bc
    • Q
      SYSFS: use standard magic.h for sysfs · 8231f2f9
      Qinghuang Feng 提交于
      SYSFS_MAGIC has been added into magic.h, so only use that definition
      in magic.h to avoid potential consistency problem.
      Signed-off-by: NQinghuang Feng <qhfeng.kernel@gmail.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      8231f2f9
  11. 22 1月, 2009 1 次提交
  12. 21 1月, 2009 1 次提交
  13. 06 1月, 2009 1 次提交
  14. 23 10月, 2008 1 次提交
  15. 17 10月, 2008 6 次提交
    • E
      kobject: Cleanup kobject_rename and !CONFIG_SYSFS · 0b4a4fea
      Eric W. Biederman 提交于
      It finally dawned on me what the clean fix to sysfs_rename_dir
      calling kobject_set_name is.  Move the work into kobject_rename
      where it belongs.  The callers serialize us anyway so this is
      safe.
      Signed-off-by: NEric W. Biederman <ebiederm@xmission.com>
      Acked-by: NTejun Heo <tj@kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      0b4a4fea
    • T
      sysfs: Make dir and name args to sysfs_notify() const · 8c0e3998
      Trent Piepho 提交于
      Because they can be, and because code like this produces a warning if
      they're not:
      
      struct device_attribute dev_attr;
      
      sysfs_notify(&kobj, NULL, dev_attr.attr.name);
      Signed-off-by: NTrent Piepho <tpiepho@freescale.com>
      CC: Neil Brown <neilb@suse.de>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      8c0e3998
    • 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
  16. 27 7月, 2008 1 次提交
  17. 22 7月, 2008 2 次提交
  18. 15 5月, 2008 1 次提交
  19. 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
  20. 30 4月, 2008 2 次提交
  21. 23 4月, 2008 1 次提交
  22. 20 4月, 2008 2 次提交
  23. 18 4月, 2008 1 次提交
  24. 25 3月, 2008 1 次提交
  25. 08 2月, 2008 1 次提交
    • G
      sysfs: remove BUG_ON() from sysfs_remove_group() · 969affd2
      Greg Kroah-Hartman 提交于
      It's possible that the caller of sysfs_remove_group messed up and passed in an attribute group that was not really registered to this kobject.  But don't panic for such a foolish error, spit out a warning about what happened, and continue on our way safely.
      
      Cc: Roland Dreier <rdreier@cisco.com>
      Cc: Tejun Heo <htejun@gmail.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      969affd2