1. 25 3月, 2015 2 次提交
  2. 27 1月, 2015 1 次提交
  3. 08 11月, 2014 2 次提交
    • S
      driver core: fix race with userland in device_add() · 0cd75047
      Sergey Klyaus 提交于
      bus_add_device() should be called before devtmpfs_create_node(), so when
      userland application opens device from devtmpfs, it wouldn't get ENODEV
      from kernel, because device_add() wasn't completed.
      Signed-off-by: NSergey Klyaus <Sergey.Klyaus@Tune-IT.Ru>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      0cd75047
    • Y
      sysfs: driver core: Fix glue dir race condition by gdp_mutex · e4a60d13
      Yijing Wang 提交于
      There is a race condition when removing glue directory.
      It can be reproduced in following test:
      
      path 1: Add first child device
      device_add()
          get_device_parent()
                  /*find parent from glue_dirs.list*/
                  list_for_each_entry(k, &dev->class->p->glue_dirs.list, entry)
                          if (k->parent == parent_kobj) {
                                  kobj = kobject_get(k);
                                  break;
                          }
                  ....
                  class_dir_create_and_add()
      
      path2: Remove last child device under glue dir
      device_del()
          cleanup_device_parent()
                  cleanup_glue_dir()
                          kobject_put(glue_dir);
      
      If path2 has been called cleanup_glue_dir(), but not
      call kobject_put(glue_dir), the glue dir is still
      in parent's kset list. Meanwhile, path1 find the glue
      dir from the glue_dirs.list. Path2 may release glue dir
      before path1 call kobject_get(). So kernel will report
      the warning and bug_on.
      
      This is a "classic" problem we have of a kref in a list
      that can be found while the last instance could be removed
      at the same time.
      
      This patch reuse gdp_mutex to fix this race condition.
      
      The following calltrace is captured in kernel 3.4, but
      the latest kernel still has this bug.
      
      -----------------------------------------------------
      <4>[ 3965.441471] WARNING: at ...include/linux/kref.h:41 kobject_get+0x33/0x40()
      <4>[ 3965.441474] Hardware name: Romley
      <4>[ 3965.441475] Modules linked in: isd_iop(O) isd_xda(O)...
      ...
      <4>[ 3965.441605] Call Trace:
      <4>[ 3965.441611]  [<ffffffff8103717a>] warn_slowpath_common+0x7a/0xb0
      <4>[ 3965.441615]  [<ffffffff810371c5>] warn_slowpath_null+0x15/0x20
      <4>[ 3965.441618]  [<ffffffff81215963>] kobject_get+0x33/0x40
      <4>[ 3965.441624]  [<ffffffff812d1e45>] get_device_parent.isra.11+0x135/0x1f0
      <4>[ 3965.441627]  [<ffffffff812d22d4>] device_add+0xd4/0x6d0
      <4>[ 3965.441631]  [<ffffffff812d0dbc>] ? dev_set_name+0x3c/0x40
      ....
      <2>[ 3965.441912] kernel BUG at ..../fs/sysfs/group.c:65!
      <4>[ 3965.441915] invalid opcode: 0000 [#1] SMP
      ...
      <4>[ 3965.686743]  [<ffffffff811a677e>] sysfs_create_group+0xe/0x10
      <4>[ 3965.686748]  [<ffffffff810cfb04>] blk_trace_init_sysfs+0x14/0x20
      <4>[ 3965.686753]  [<ffffffff811fcabb>] blk_register_queue+0x3b/0x120
      <4>[ 3965.686756]  [<ffffffff812030bc>] add_disk+0x1cc/0x490
      ....
      -------------------------------------------------------
      Signed-off-by: NYijing Wang <wangyijing@huawei.com>
      Signed-off-by: NWeng Meiling <wengmeiling.weng@huawei.com>
      Cc: <stable@vger.kernel.org> #3.4+
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e4a60d13
  4. 02 10月, 2014 1 次提交
    • J
      driver core: Add BUS_NOTIFY_REMOVED_DEVICE event · 599bad38
      Joerg Roedel 提交于
      This event closes an important gap in the bus notifiers.
      There is already the BUS_NOTIFY_DEL_DEVICE event, but that
      is sent when the device is still bound to its device driver.
      
      This is too early for the IOMMU code to destroy any mappings
      for the device, as they might still be in use by the driver.
      
      The new BUS_NOTIFY_REMOVED_DEVICE event introduced with this
      patch closes this gap as it is sent when the device is
      already unbound from its device driver and almost completly
      removed from the driver core.
      
      With this event the IOMMU code can safely destroy any
      mappings and other data structures when a device is removed.
      Signed-off-by: NJoerg Roedel <jroedel@suse.de>
      Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Tested-by: NJerry Hoemann <jerry.hoemann@hp.com>
      599bad38
  5. 24 9月, 2014 1 次提交
  6. 17 4月, 2014 1 次提交
  7. 26 3月, 2014 1 次提交
  8. 10 3月, 2014 1 次提交
  9. 09 3月, 2014 1 次提交
    • R
      Revert "driver core: synchronize device shutdown" · aa0689b3
      Roland Dreier 提交于
      This reverts commit 401097ea.  The
      original changelog said:
      
          A patch series to make .shutdown execute asynchronously.  Some drivers's
          shutdown can take a lot of time.  The patches can help save some shutdown
          time.  The patches use Arjan's async API.
      
          This patch:
      
          synchronize all tasks submitted by .shutdown
      
      However, I'm not able to find any evidence that any other patches from
      this series were applied, nor am I able to find any async tasks that are
      scheduled in a .shutdown context.
      
      On the other hand, we see occasional hangs on shutdown that appear to be
      caused by the async_synchronize_full() in device_shutdown() waiting
      forever for the async probing in sd if a SCSI disk shows up at just the
      wrong time — the system starts the probe, but begins shutting down and
      tears down too much of the SCSI driver to finish the probe.
      
      If we had any async shutdown tasks, I guess the right fix would be to
      create a "shutdown" async domain and have device_shutdown() only wait
      for that domain.  But since there apparently are no async shutdown
      tasks, we can just revert the waiting.
      Signed-off-by: NRoland Dreier <roland@purestorage.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      aa0689b3
  10. 16 2月, 2014 1 次提交
  11. 08 2月, 2014 2 次提交
    • T
      sysfs, driver-core: remove unused {sysfs|device}_schedule_callback_owner() · ce8b04aa
      Tejun Heo 提交于
      All device_schedule_callback_owner() users are converted to use
      device_remove_file_self().  Remove now unused
      {sysfs|device}_schedule_callback_owner().
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ce8b04aa
    • T
      kernfs, sysfs, driver-core: implement kernfs_remove_self() and its wrappers · 6b0afc2a
      Tejun Heo 提交于
      Sometimes it's necessary to implement a node which wants to delete
      nodes including itself.  This isn't straightforward because of kernfs
      active reference.  While a file operation is in progress, an active
      reference is held and kernfs_remove() waits for all such references to
      drain before completing.  For a self-deleting node, this is a deadlock
      as kernfs_remove() ends up waiting for an active reference that itself
      is sitting on top of.
      
      This currently is worked around in the sysfs layer using
      sysfs_schedule_callback() which makes such removals asynchronous.
      While it works, it's rather cumbersome and inherently breaks
      synchronicity of the operation - the file operation which triggered
      the operation may complete before the removal is finished (or even
      started) and the removal may fail asynchronously.  If a removal
      operation is immmediately followed by another operation which expects
      the specific name to be available (e.g. removal followed by rename
      onto the same name), there's no way to make the latter operation
      reliable.
      
      The thing is there's no inherent reason for this to be asynchrnous.
      All that's necessary to do this synchronous is a dedicated operation
      which drops its own active ref and deactivates self.  This patch
      implements kernfs_remove_self() and its wrappers in sysfs and driver
      core.  kernfs_remove_self() is to be called from one of the file
      operations, drops the active ref the task is holding, removes the self
      node, and restores active ref to the dead node so that the ref is
      balanced afterwards.  __kernfs_remove() is updated so that it takes an
      early exit if the target node is already fully removed so that the
      active ref restored by kernfs_remove_self() after removal doesn't
      confuse the deactivation path.
      
      This makes implementing self-deleting nodes very easy.  The normal
      removal path doesn't even need to be changed to use
      kernfs_remove_self() for the self-deleting node.  The method can
      invoke kernfs_remove_self() on itself before proceeding the normal
      removal path.  kernfs_remove() invoked on the node by the normal
      deletion path will simply be ignored.
      
      This will replace sysfs_schedule_callback().  A subtle feature of
      sysfs_schedule_callback() is that it collapses multiple invocations -
      even if multiple removals are triggered, the removal callback is run
      only once.  An equivalent effect can be achieved by testing the return
      value of kernfs_remove_self() - only the one which gets %true return
      value should proceed with actual deletion.  All other instances of
      kernfs_remove_self() will wait till the enclosing kernfs operation
      which invoked the winning instance of kernfs_remove_self() finishes
      and then return %false.  This trivially makes all users of
      kernfs_remove_self() automatically show correct synchronous behavior
      even when there are multiple concurrent operations - all "echo 1 >
      delete" instances will finish only after the whole operation is
      completed by one of the instances.
      
      Note that manipulation of active ref is implemented in separate public
      functions - kernfs_[un]break_active_protection().
      kernfs_remove_self() is the only user at the moment but this will be
      used to cater to more complex cases.
      
      v2: For !CONFIG_SYSFS, dummy version kernfs_remove_self() was missing
          and sysfs_remove_file_self() had incorrect return type.  Fix it.
          Reported by kbuild test bot.
      
      v3: kernfs_[un]break_active_protection() separated out from
          kernfs_remove_self() and exposed as public API.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Cc: Alan Stern <stern@rowland.harvard.edu>
      Cc: kbuild test robot <fengguang.wu@intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6b0afc2a
  12. 14 1月, 2014 2 次提交
  13. 11 1月, 2014 2 次提交
    • T
      sysfs, driver-core: remove unused {sysfs|device}_schedule_callback_owner() · d1ba277e
      Tejun Heo 提交于
      All device_schedule_callback_owner() users are converted to use
      device_remove_file_self().  Remove now unused
      {sysfs|device}_schedule_callback_owner().
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d1ba277e
    • T
      kernfs, sysfs, driver-core: implement kernfs_remove_self() and its wrappers · 1ae06819
      Tejun Heo 提交于
      Sometimes it's necessary to implement a node which wants to delete
      nodes including itself.  This isn't straightforward because of kernfs
      active reference.  While a file operation is in progress, an active
      reference is held and kernfs_remove() waits for all such references to
      drain before completing.  For a self-deleting node, this is a deadlock
      as kernfs_remove() ends up waiting for an active reference that itself
      is sitting on top of.
      
      This currently is worked around in the sysfs layer using
      sysfs_schedule_callback() which makes such removals asynchronous.
      While it works, it's rather cumbersome and inherently breaks
      synchronicity of the operation - the file operation which triggered
      the operation may complete before the removal is finished (or even
      started) and the removal may fail asynchronously.  If a removal
      operation is immmediately followed by another operation which expects
      the specific name to be available (e.g. removal followed by rename
      onto the same name), there's no way to make the latter operation
      reliable.
      
      The thing is there's no inherent reason for this to be asynchrnous.
      All that's necessary to do this synchronous is a dedicated operation
      which drops its own active ref and deactivates self.  This patch
      implements kernfs_remove_self() and its wrappers in sysfs and driver
      core.  kernfs_remove_self() is to be called from one of the file
      operations, drops the active ref and deactivates using
      __kernfs_deactivate_self(), removes the self node, and restores active
      ref to the dead node using __kernfs_reactivate_self() so that the ref
      is balanced afterwards.  __kernfs_remove() is updated so that it takes
      an early exit if the target node is already fully removed so that the
      active ref restored by kernfs_remove_self() after removal doesn't
      confuse the deactivation path.
      
      This makes implementing self-deleting nodes very easy.  The normal
      removal path doesn't even need to be changed to use
      kernfs_remove_self() for the self-deleting node.  The method can
      invoke kernfs_remove_self() on itself before proceeding the normal
      removal path.  kernfs_remove() invoked on the node by the normal
      deletion path will simply be ignored.
      
      This will replace sysfs_schedule_callback().  A subtle feature of
      sysfs_schedule_callback() is that it collapses multiple invocations -
      even if multiple removals are triggered, the removal callback is run
      only once.  An equivalent effect can be achieved by testing the return
      value of kernfs_remove_self() - only the one which gets %true return
      value should proceed with actual deletion.  All other instances of
      kernfs_remove_self() will wait till the enclosing kernfs operation
      which invoked the winning instance of kernfs_remove_self() finishes
      and then return %false.  This trivially makes all users of
      kernfs_remove_self() automatically show correct synchronous behavior
      even when there are multiple concurrent operations - all "echo 1 >
      delete" instances will finish only after the whole operation is
      completed by one of the instances.
      
      v2: For !CONFIG_SYSFS, dummy version kernfs_remove_self() was missing
          and sysfs_remove_file_self() had incorrect return type.  Fix it.
          Reported by kbuild test bot.
      
      v3: Updated to use __kernfs_{de|re}activate_self().
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Cc: Alan Stern <stern@rowland.harvard.edu>
      Cc: kbuild test robot <fengguang.wu@intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      1ae06819
  14. 19 12月, 2013 1 次提交
  15. 09 12月, 2013 1 次提交
  16. 17 10月, 2013 1 次提交
  17. 06 10月, 2013 2 次提交
  18. 27 9月, 2013 2 次提交
    • T
      sysfs: remove ktype->namespace() invocations in symlink code · 4b30ee58
      Tejun Heo 提交于
      There's no reason for sysfs to be calling ktype->namespace().  It is
      backwards, obfuscates what's going on and unnecessarily tangles two
      separate layers.
      
      There are two places where symlink code calls ktype->namespace().
      
      * sysfs_do_create_link_sd() calls it to find out the namespace tag of
        the target directory.  Unless symlinking races with cross-namespace
        renaming, this equals @target_sd->s_ns.
      
      * sysfs_rename_link() uses it to find out the new namespace to rename
        to and the new namespace can be different from the existing one.
        The function is renamed to sysfs_rename_link_ns() with an explicit
        @ns argument and the ktype->namespace() invocation is shifted to the
        device layer.
      
      While this patch replaces ktype->namespace() invocation with the
      recorded result in @target_sd, this shouldn't result in any behvior
      difference.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Cc: Eric W. Biederman <ebiederm@xmission.com>
      Cc: Kay Sievers <kay@vrfy.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      4b30ee58
    • B
      driver core : Fix use after free of dev->parent in device_shutdown · f123db8e
      Benson Leung 提交于
      The put_device(dev) at the bottom of the loop of device_shutdown
      may result in the dev being cleaned up. In device_create_release,
      the dev is kfreed.
      
      However, device_shutdown attempts to use the dev pointer again after
      put_device by referring to dev->parent.
      
      Copy the parent pointer instead to avoid this condition.
      
      This bug was found on Chromium OS's chromeos-3.8, which is based on v3.8.11.
      See bug report : https://code.google.com/p/chromium/issues/detail?id=297842
      This can easily be reproduced when shutting down with
      hidraw devices that report battery condition.
      Two examples are the HP Bluetooth Mouse X4000b and the Apple Magic Mouse.
      For example, with the magic mouse :
      The dev in question is "hidraw0"
      dev->parent is "magicmouse"
      
      In the course of the shutdown for this device, the input event cleanup calls
      a put on hidraw0, decrementing its reference count.
      When we finally get to put_device(dev) in device_shutdown, kobject_cleanup
      is called and device_create_release does kfree(dev).
      dev->parent is no longer valid, and we may crash in
      put_device(dev->parent).
      
      This change should be applied on any kernel with this change :
      d1c6c030
      
      Cc: stable@vger.kernel.org
      Signed-off-by: NBenson Leung <bleung@chromium.org>
      Reviewed-by: NMing Lei <ming.lei@canonical.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f123db8e
  19. 30 8月, 2013 1 次提交
    • R
      driver core / ACPI: Avoid device hot remove locking issues · 5e33bc41
      Rafael J. Wysocki 提交于
      device_hotplug_lock is held around the acpi_bus_trim() call in
      acpi_scan_hot_remove() which generally removes devices (it removes
      ACPI device objects at least, but it may also remove "physical"
      device objects through .detach() callbacks of ACPI scan handlers).
      Thus, potentially, device sysfs attributes are removed under that
      lock and to remove those attributes it is necessary to hold the
      s_active references of their directory entries for writing.
      
      On the other hand, the execution of a .show() or .store() callback
      from a sysfs attribute is carried out with that attribute's s_active
      reference held for reading.  Consequently, if any device sysfs
      attribute that may be removed from within acpi_scan_hot_remove()
      through acpi_bus_trim() has a .store() or .show() callback which
      acquires device_hotplug_lock, the execution of that callback may
      deadlock with the removal of the attribute.  [Unfortunately, the
      "online" device attribute of CPUs and memory blocks is one of them.]
      
      To avoid such deadlocks, make all of the sysfs attribute callbacks
      that need to lock device hotplug, for example store_online(), use
      a special function, lock_device_hotplug_sysfs(), to lock device
      hotplug and return the result of that function immediately if it is
      not zero.  This will cause the s_active reference of the directory
      entry in question to be released and the syscall to be restarted
      if device_hotplug_lock cannot be acquired.
      
      [show_online() actually doesn't need to lock device hotplug, but
      it is useful to serialize it with respect to device_offline() and
      device_online() for the same device (in case user space attempts to
      run them concurrently) which can be done with the help of
      device_lock().]
      Reported-by: NYasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
      Reported-and-tested-by: NGu Zheng <guz.fnst@cn.fujitsu.com>
      Suggested-by: NTejun Heo <tj@kernel.org>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Acked-by: NToshi Kani <toshi.kani@hp.com>
      5e33bc41
  20. 28 8月, 2013 1 次提交
  21. 24 8月, 2013 1 次提交
  22. 23 8月, 2013 1 次提交
    • G
      sysfs.h: remove attr_name() macro · 3e1026b3
      Greg Kroah-Hartman 提交于
      Gotta love a macro that doesn't reduce the typing you have to do.
      
      Also, only the driver core, and one network driver uses this.  The
      driver core functions will be going away soon, and I'll convert the
      network driver soon to not need this as well, so delete it for now
      before anyone else gets some bright ideas and wants to use it.
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3e1026b3
  23. 22 8月, 2013 1 次提交
  24. 20 8月, 2013 1 次提交
  25. 13 8月, 2013 1 次提交
  26. 27 7月, 2013 2 次提交
  27. 17 7月, 2013 2 次提交
  28. 04 6月, 2013 1 次提交
  29. 22 5月, 2013 2 次提交
  30. 12 5月, 2013 1 次提交
    • R
      Driver core: Add offline/online device operations · 4f3549d7
      Rafael J. Wysocki 提交于
      In some cases, graceful hot-removal of devices is not possible,
      although in principle the devices in question support hotplug.
      For example, that may happen for the last CPU in the system or
      for memory modules holding kernel memory.
      
      In those cases it is nice to be able to check if the given device
      can be gracefully hot-removed before triggering a removal procedure
      that cannot be aborted or reversed.  Unfortunately, however, the
      kernel currently doesn't provide any support for that.
      
      To address that deficiency, introduce support for offline and
      online operations that can be performed on devices, respectively,
      before a hot-removal and in case when it is necessary (or convenient)
      to put a device back online after a successful offline (that has not
      been followed by removal).  The idea is that the offline will fail
      whenever the given device cannot be gracefully removed from the
      system and it will not be allowed to use the device after a
      successful offline (until a subsequent online) in analogy with the
      existing CPU offline/online mechanism.
      
      For now, the offline and online operations are introduced at the
      bus type level, as that should be sufficient for the most urgent use
      cases (CPUs and memory modules).  In the future, however, the
      approach may be extended to cover some more complicated device
      offline/online scenarios involving device drivers etc.
      
      The lock_device_hotplug() and unlock_device_hotplug() functions are
      introduced because subsequent patches need to put larger pieces of
      code under device_hotplug_lock to prevent race conditions between
      device offline and removal from happening.
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Reviewed-by: NToshi Kani <toshi.kani@hp.com>
      4f3549d7