1. 21 Aug, 2013 4 commits
  2. 07 Jun, 2013 1 commit
  3. 17 Jan, 2013 2 commits
  4. 27 Nov, 2012 1 commit
  5. 24 Jan, 2012 1 commit
    • Eric W. Biederman's avatar
      sysfs: Complain bitterly about attempts to remove files from nonexistent directories. · ce597919
      Eric W. Biederman authored
      Recently an OOPS was observed from the usb serial io_ti driver when it tried to remove
      sysfs directories.  Upon investigation it turns out this driver was always buggy
      and that a recent sysfs change had stopped guarding itself against removing attributes
      from sysfs directories that had already been removed. :(
      Historically we have been silent about attempting to files from nonexistent sysfs
      directories and have politely returned error codes.  That has resulted in people writing
      broken code that ignores the error codes.
      Issue a kernel WARNING and a stack backtrace to make it clear in no uncertain
      terms that abusing sysfs is not ok, and the callers need to fix their code.
      This change transforms the io_ti OOPS into a more comprehensible error message
      and stack backtrace.
      Signed-off-by: default avatarEric W. Biederman <ebiederm@xmission.com>
      Reported-by: default avatarWolfgang Frisch <wfpub@roembden.net>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
  6. 04 Jan, 2012 2 commits
  7. 19 Oct, 2011 2 commits
    • Eric W. Biederman's avatar
      sysfs: Reject with a warning invalid uses of tagged directories. · 903e21e2
      Eric W. Biederman authored
      sysfs is a core piece of ifrastructure that many people use and
      few people have all of the rules in their head on how to use
      it correctly.  Add warnings for people using tagged directories
      improperly to that any misuses can be caught and diagnosed quickly.
      A single inexpensive test in sysfs_find_dirent is almost sufficient
      to catch all possible misuses.  An additional warning is needed
      in sysfs_add_dirent so that we actually fail when attempting to
      add an untagged dirent in a tagged directory.
      Signed-off-by: default avatarEric W. Biederman <ebiederm@xmission.com>
      Acked-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    • Eric W. Biederman's avatar
      sysfs: Implement support for tagged files in sysfs. · 487505c2
      Eric W. Biederman authored
      Looking up files in sysfs is hard to understand and analyize because we
      currently allow placing untagged files in tagged directories.  In the
      implementation of that we have two subtly different meanings of NULL.
      NULL meaning there is no tag on a directory entry and NULL meaning
      we don't care which namespace the lookup is performed for.  This
      multiple uses of NULL have resulted in subtle bugs (since fixed)
      in the code.
      Currently it is only the bonding driver that needs to have an untagged
      file in a tagged directory.
      To untagle this mess I am adding support for tagged files to sysfs.
      Modifying the bonding driver to implement bonding_masters as a tagged
      file.  Registering bonding_masters once for each network namespace.
      Then I am removing support for untagged entries in tagged sysfs
      Resulting in code that is much easier to reason about.
      Signed-off-by: default avatarEric W. Biederman <ebiederm@xmission.com>
      Acked-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
  8. 13 May, 2011 1 commit
  9. 04 Sep, 2010 1 commit
  10. 05 Aug, 2010 1 commit
  11. 21 May, 2010 1 commit
    • Eric W. Biederman's avatar
      sysfs: Implement sysfs tagged directory support. · 3ff195b0
      Eric W. Biederman authored
      The problem.  When implementing a network namespace I need to be able
      to have multiple network devices with the same name.  Currently this
      is a problem for /sys/class/net/*, /sys/devices/virtual/net/*, and
      potentially a few other directories of the form /sys/ ... /net/*.
      What this patch does is to add an additional tag field to the
      sysfs dirent structure.  For directories that should show different
      contents depending on the context such as /sys/class/net/, and
      /sys/devices/virtual/net/ this tag field is used to specify the
      context in which those directories should be visible.  Effectively
      this is the same as creating multiple distinct directories with
      the same name but internally to sysfs the result is nicer.
      I am calling the concept of a single directory that looks like multiple
      directories all at the same path in the filesystem tagged directories.
      For the networking namespace the set of directories whose contents I need
      to filter with tags can depend on the presence or absence of hotplug
      hardware or which modules are currently loaded.  Which means I need
      a simple race free way to setup those directories as tagged.
      To achieve a reace free design all tagged directories are created
      and managed by sysfs itself.
      Users of this interface:
      - define a type in the sysfs_tag_type enumeration.
      - call sysfs_register_ns_types with the type and it's operations
      - sysfs_exit_ns when an individual tag is no longer valid
      - Implement mount_ns() which returns the ns of the calling process
        so we can attach it to a sysfs superblock.
      - Implement ktype.namespace() which returns the ns of a syfs kobject.
      Everything else is left up to sysfs and the driver layer.
      For the network namespace mount_ns and namespace() are essentially
      one line functions, and look to remain that.
      Tags are currently represented a const void * pointers as that is
      both generic, prevides enough information for equality comparisons,
      and is trivial to create for current users, as it is just the
      existing namespace pointer.
      The work needed in sysfs is more extensive.  At each directory
      or symlink creating I need to check if the directory it is being
      created in is a tagged directory and if so generate the appropriate
      tag to place on the sysfs_dirent.  Likewise at each symlink or
      directory removal I need to check if the sysfs directory it is
      being removed from is a tagged directory and if so figure out
      which tag goes along with the name I am deleting.
      Currently only directories which hold kobjects, and
      symlinks are supported.  There is not enough information
      in the current file attribute interfaces to give us anything
      to discriminate on which makes it useless, and there are
      no potential users which makes it an uninteresting problem
      to solve.
      Signed-off-by: default avatarEric W. Biederman <ebiederm@xmission.com>
      Signed-off-by: default avatarBenjamin Thery <benjamin.thery@bull.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
  12. 08 Mar, 2010 4 commits
  13. 11 Dec, 2009 2 commits
  14. 14 Oct, 2009 1 commit
    • Neil Brown's avatar
      sysfs: Allow sysfs_notify_dirent to be called from interrupt context. · 83db93f4
      Neil Brown authored
      sysfs_notify_dirent is a simple atomic operation that can be used to
      alert user-space that new data can be read from a sysfs attribute.
      Unfortunately it cannot currently be called from non-process context
      because of its use of spin_lock which is sometimes taken with
      interrupts enabled.
      So change all lockers of sysfs_open_dirent_lock to disable interrupts,
      thus making sysfs_notify_dirent safe to be called from non-process
      context (as drivers/md does in md_safemode_timeout).
      sysfs_get_open_dirent is (documented as being) only called from
      process context, so it uses spin_lock_irq.  Other places
      use spin_lock_irqsave.
      The usage for sysfs_notify_dirent in md_safemode_timeout was
      introduced in 2.6.28, so this patch is suitable for that and more
      recent kernels.
      Reported-by: default avatarJoel Andres Granados <jgranado@redhat.com>
      Signed-off-by: default avatarNeilBrown <neilb@suse.de>
      Signed-off-by: default avatarDan Williams <dan.j.williams@intel.com>
      Cc: stable <stable@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
  15. 28 May, 2009 1 commit
  16. 16 Apr, 2009 2 commits
    • KOSAKI Motohiro's avatar
      sysfs: sysfs poll keep the poll rule of regular file. · 1af3557a
      KOSAKI Motohiro authored
      Currently, following test programs don't finished.
      % ruby -e '
      Thread.new { sleep }
      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
      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: default avatarKOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
    • Alex Chiang's avatar
      sysfs: don't use global workqueue in sysfs_schedule_callback() · d110271e
      Alex Chiang authored
      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
      Reported-by: default avatarKenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
      Tested-by: default avatarKenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
      Signed-off-by: default avatarAlex Chiang <achiang@hp.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
  17. 24 Mar, 2009 1 commit
    • Alex Chiang's avatar
      sysfs: only allow one scheduled removal callback per kobj · 66942064
      Alex Chiang authored
      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: default avatar <vegard.nossum@gmail.com>
      Signed-off-by: default avatarAlex Chiang <achiang@hp.com>
      Acked-by: default avatarCornelia Huck <cornelia.huck@de.ibm.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
  18. 16 Oct, 2008 3 commits
  19. 26 Jul, 2008 1 commit
  20. 22 Jul, 2008 1 commit
  21. 30 Apr, 2008 1 commit
  22. 22 Apr, 2008 1 commit
  23. 20 Apr, 2008 2 commits
  24. 25 Mar, 2008 1 commit
  25. 25 Jan, 2008 2 commits