1. 26 Sep, 2013 2 commits
    • Tejun Heo's avatar
      sysfs: clean up sysfs_get_dirent() · 388975cc
      Tejun Heo authored
      The pre-existing sysfs interfaces which take explicit namespace
      argument are weird in that they place the optional @ns in front of
      @name which is contrary to the established convention.  For example,
      we end up forcing vast majority of sysfs_get_dirent() users to do
      sysfs_get_dirent(parent, NULL, name), which is silly and error-prone
      especially as @ns and @name may be interchanged without causing
      compilation warning.
      This renames sysfs_get_dirent() to sysfs_get_dirent_ns() and swap the
      positions of @name and @ns, and sysfs_get_dirent() is now a wrapper
      around sysfs_get_dirent_ns().  This makes confusions a lot less
      There are other interfaces which take @ns before @name.  They'll be
      updated by following patches.
      This patch doesn't introduce any functional changes.
      v2: EXPORT_SYMBOL_GPL() wasn't updated leading to undefined symbol
          error on module builds.  Reported by build test robot.  Fixed.
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      Cc: Eric W. Biederman <ebiederm@xmission.com>
      Cc: Kay Sievers <kay@vrfy.org>
      Cc: Fengguang Wu <fengguang.wu@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Tejun Heo's avatar
      sysfs: make attr namespace interface less convoluted · 58292cbe
      Tejun Heo authored
      sysfs ns (namespace) implementation became more convoluted than
      necessary while trying to hide ns information from visible interface.
      The relatively recent attr ns support is a good example.
      * attr ns tag is determined by sysfs_ops->namespace() callback while
        dir tag is determined by kobj_type->namespace().  The placement is
      * Instead of performing operations with explicit ns tag, the namespace
        callback is routed through sysfs_attr_ns(), sysfs_ops->namespace(),
        class_attr_namespace(), class_attr->namespace().  It's not simpler
        in any sense.  The only thing this convolution does is traversing
        the whole stack backwards.
      The namespace callbacks are unncessary because the operations involved
      are inherently synchronous.  The information can be provided in in
      straight-forward top-down direction and reversing that direction is
      unnecessary and against basic design principles.
      This backward interface is unnecessarily convoluted and hinders
      properly separating out sysfs from driver model / kobject for proper
      layering.  This patch updates attr ns support such that
      * sysfs_ops->namespace() and class_attr->namespace() are dropped.
      * sysfs_{create|remove}_file_ns(), which take explicit @ns param, are
        added and sysfs_{create|remove}_file() are now simple wrappers
        around the ns aware functions.
      * ns handling is dropped from sysfs_chmod_file().  Nobody uses it at
        this point.  sysfs_chmod_file_ns() can be added later if necessary.
      * Explicit @ns is propagated through class_{create|remove}_file_ns()
        and netdev_class_{create|remove}_file_ns().
      * driver/net/bonding which is currently the only user of attr
        namespace is updated to use netdev_class_{create|remove}_file_ns()
        with @bh->net as the ns tag instead of using the namespace callback.
      This patch should be an equivalent conversion without any functional
      difference.  It makes the code easier to follow, reduces lines of code
      a bit and helps proper separation and layering.
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      Cc: Eric W. Biederman <ebiederm@xmission.com>
      Cc: Kay Sievers <kay@vrfy.org>
      Acked-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
  2. 21 Aug, 2013 6 commits
  3. 07 Jun, 2013 1 commit
  4. 17 Jan, 2013 2 commits
  5. 27 Nov, 2012 1 commit
  6. 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>
  7. 04 Jan, 2012 2 commits
  8. 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>
  9. 13 May, 2011 1 commit
  10. 04 Sep, 2010 1 commit
  11. 05 Aug, 2010 1 commit
  12. 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>
  13. 08 Mar, 2010 4 commits
  14. 11 Dec, 2009 2 commits
  15. 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>
  16. 28 May, 2009 1 commit
  17. 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>
  18. 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>
  19. 16 Oct, 2008 3 commits
  20. 26 Jul, 2008 1 commit
  21. 22 Jul, 2008 1 commit
  22. 30 Apr, 2008 1 commit
  23. 22 Apr, 2008 1 commit
  24. 20 Apr, 2008 1 commit
    • Dan Williams's avatar
      sysfs: refill attribute buffer when reading from offset 0 · 2424b5dd
      Dan Williams authored
      Requiring userspace to close and re-open sysfs attributes has been the
      policy since before 2.6.12.  It allows userspace to get a consistent
      snapshot of kernel state and consume it with incremental reads and seeks.
      Now, if the file position is zero the kernel assumes userspace wants to see
      the new value.  The application for this change is to allow a userspace
      RAID metadata handler to check the state of an array without causing any
      memory allocations.  Thus not causing writeback to a raid array that might
      be blocked waiting for userspace to take action.
      Cc: Neil Brown <neilb@suse.de>
      Acked-by: default avatarTejun Heo <htejun@gmail.com>
      Signed-off-by: default avatarDan Williams <dan.j.williams@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>