1. 25 10月, 2017 1 次提交
    • M
      locking/atomics: COCCINELLE/treewide: Convert trivial ACCESS_ONCE() patterns... · 6aa7de05
      Mark Rutland 提交于
      locking/atomics: COCCINELLE/treewide: Convert trivial ACCESS_ONCE() patterns to READ_ONCE()/WRITE_ONCE()
      
      Please do not apply this to mainline directly, instead please re-run the
      coccinelle script shown below and apply its output.
      
      For several reasons, it is desirable to use {READ,WRITE}_ONCE() in
      preference to ACCESS_ONCE(), and new code is expected to use one of the
      former. So far, there's been no reason to change most existing uses of
      ACCESS_ONCE(), as these aren't harmful, and changing them results in
      churn.
      
      However, for some features, the read/write distinction is critical to
      correct operation. To distinguish these cases, separate read/write
      accessors must be used. This patch migrates (most) remaining
      ACCESS_ONCE() instances to {READ,WRITE}_ONCE(), using the following
      coccinelle script:
      
      ----
      // Convert trivial ACCESS_ONCE() uses to equivalent READ_ONCE() and
      // WRITE_ONCE()
      
      // $ make coccicheck COCCI=/home/mark/once.cocci SPFLAGS="--include-headers" MODE=patch
      
      virtual patch
      
      @ depends on patch @
      expression E1, E2;
      @@
      
      - ACCESS_ONCE(E1) = E2
      + WRITE_ONCE(E1, E2)
      
      @ depends on patch @
      expression E;
      @@
      
      - ACCESS_ONCE(E)
      + READ_ONCE(E)
      ----
      Signed-off-by: NMark Rutland <mark.rutland@arm.com>
      Signed-off-by: NPaul E. McKenney <paulmck@linux.vnet.ibm.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: davem@davemloft.net
      Cc: linux-arch@vger.kernel.org
      Cc: mpe@ellerman.id.au
      Cc: shuah@kernel.org
      Cc: snitzer@redhat.com
      Cc: thor.thayer@linux.intel.com
      Cc: tj@kernel.org
      Cc: viro@zeniv.linux.org.uk
      Cc: will.deacon@arm.com
      Link: http://lkml.kernel.org/r/1508792849-3115-19-git-send-email-paulmck@linux.vnet.ibm.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
      6aa7de05
  2. 20 10月, 2017 1 次提交
  3. 17 10月, 2017 1 次提交
  4. 29 8月, 2017 1 次提交
  5. 22 7月, 2017 2 次提交
  6. 07 7月, 2017 1 次提交
  7. 13 6月, 2017 1 次提交
    • J
      driver core: add helper to reuse a device-tree node · 4e75e1d7
      Johan Hovold 提交于
      Add a helper function to be used when reusing the device-tree node of
      another device.
      
      It is fairly common for drivers to reuse the device-tree node of a
      parent (or other ancestor) device when creating class or bus devices
      (e.g. gpio chips, i2c adapters, iio chips, spi masters, serdev, phys,
      usb root hubs). But reusing a device-tree node may cause problems if the
      new device is later probed as for example driver core would currently
      attempt to reinitialise an already active associated pinmux
      configuration.
      
      Other potential issues include the platform-bus code unconditionally
      dropping the device-tree node reference in its device destructor,
      reinitialisation of other bus-managed resources such as clocks, and the
      recently added DMA-setup in driver core.
      
      Note that for most examples above this is currently not an issue as the
      devices are never probed, but this is a problem for the USB bus which
      has recently gained device-tree support. This was discovered and
      worked-around in a rather ad-hoc fashion by commit dc5878ab ("usb:
      core: move root hub's device node assignment after it is added to bus")
      by not setting the of_node pointer until after the root-hub device has
      been registered.
      
      Instead we can allow devices to reuse a device-tree node by setting a
      flag in their struct device that can be used by core, bus and driver
      code to avoid resources from being over-allocated.
      
      Note that the helper also grabs an extra reference to the device node,
      which specifically balances the unconditional put in the platform-device
      destructor.
      Signed-off-by: NJohan Hovold <johan@kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      4e75e1d7
  8. 26 5月, 2017 1 次提交
    • P
      kobject: support passing in variables for synthetic uevents · f36776fa
      Peter Rajnoha 提交于
      This patch makes it possible to pass additional arguments in addition
      to uevent action name when writing /sys/.../uevent attribute. These
      additional arguments are then inserted into generated synthetic uevent
      as additional environment variables.
      
      Before, we were not able to pass any additional uevent environment
      variables for synthetic uevents. This made it hard to identify such uevents
      properly in userspace to make proper distinction between genuine uevents
      originating from kernel and synthetic uevents triggered from userspace.
      Also, it was not possible to pass any additional information which would
      make it possible to optimize and change the way the synthetic uevents are
      processed back in userspace based on the originating environment of the
      triggering action in userspace. With the extra additional variables, we are
      able to pass through this extra information needed and also it makes it
      possible to synchronize with such synthetic uevents as they can be clearly
      identified back in userspace.
      
      The format for writing the uevent attribute is following:
      
          ACTION [UUID [KEY=VALUE ...]
      
      There's no change in how "ACTION" is recognized - it stays the same
      ("add", "change", "remove"). The "ACTION" is the only argument required
      to generate synthetic uevent, the rest of arguments, that this patch
      adds support for, are optional.
      
      The "UUID" is considered as transaction identifier so it's possible to
      use the same UUID value for one or more synthetic uevents in which case
      we logically group these uevents together for any userspace listeners.
      The "UUID" is expected to be in "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
      format where "x" is a hex digit. The value appears in uevent as
      "SYNTH_UUID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" environment variable.
      
      The "KEY=VALUE" pairs can contain alphanumeric characters only. It's
      possible to define zero or more more pairs - each pair is then delimited
      by a space character " ". Each pair appears in synthetic uevents as
      "SYNTH_ARG_KEY=VALUE" environment variable. That means the KEY name gains
      "SYNTH_ARG_" prefix to avoid possible collisions with existing variables.
      To pass the "KEY=VALUE" pairs, it's also required to pass in the "UUID"
      part for the synthetic uevent first.
      
      If "UUID" is not passed in, the generated synthetic uevent gains
      "SYNTH_UUID=0" environment variable automatically so it's possible to
      identify this situation in userspace when reading generated uevent and so
      we can still make a difference between genuine and synthetic uevents.
      Signed-off-by: NPeter Rajnoha <prajnoha@redhat.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f36776fa
  9. 09 4月, 2017 1 次提交
  10. 17 3月, 2017 1 次提交
  11. 02 3月, 2017 1 次提交
  12. 25 2月, 2017 1 次提交
  13. 14 1月, 2017 1 次提交
  14. 05 12月, 2016 1 次提交
  15. 11 11月, 2016 1 次提交
  16. 01 11月, 2016 3 次提交
    • R
      PM / runtime: Optimize the use of device links · baa8809f
      Rafael J. Wysocki 提交于
      If the device has no links to suppliers that should be used for
      runtime PM (links with DEVICE_LINK_PM_RUNTIME set), there is no
      reason to walk the list of suppliers for that device during
      runtime suspend and resume.
      
      Add a simple mechanism to detect that case and possibly avoid the
      extra unnecessary overhead.
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      baa8809f
    • R
      PM / runtime: Use device links · 21d5c57b
      Rafael J. Wysocki 提交于
      Modify the runtime PM framework to use device links to ensure that
      supplier devices will not be suspended if any of their consumer
      devices are active.
      
      The idea is to reference count suppliers on the consumer's resume
      and drop references to them on its suspend.  The information on
      whether or not the supplier has been reference counted by the
      consumer's (runtime) resume is stored in a new field (rpm_active)
      in the link object for each link.
      
      It may be necessary to clean up those references when the
      supplier is unbinding and that's why the links whose status is
      DEVICE_LINK_SUPPLIER_UNBIND are skipped by the runtime suspend
      and resume code.
      
      The above means that if the consumer device is probed in the
      runtime-active state, the supplier has to be resumed and reference
      counted by device_link_add() so the code works as expected on its
      (runtime) suspend.  There is a new flag, DEVICE_LINK_RPM_ACTIVE,
      to tell device_link_add() about that (in which case the caller
      is responsible for making sure that the consumer really will
      be runtime-active when runtime PM is enabled for it).
      
      The other new link flag, DEVICE_LINK_PM_RUNTIME, tells the core
      whether or not the link should be used for runtime PM at all.
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      21d5c57b
    • R
      driver core: Functional dependencies tracking support · 9ed98953
      Rafael J. Wysocki 提交于
      Currently, there is a problem with taking functional dependencies
      between devices into account.
      
      What I mean by a "functional dependency" is when the driver of device
      B needs device A to be functional and (generally) its driver to be
      present in order to work properly.  This has certain consequences
      for power management (suspend/resume and runtime PM ordering) and
      shutdown ordering of these devices.  In general, it also implies that
      the driver of A needs to be working for B to be probed successfully
      and it cannot be unbound from the device before the B's driver.
      
      Support for representing those functional dependencies between
      devices is added here to allow the driver core to track them and act
      on them in certain cases where applicable.
      
      The argument for doing that in the driver core is that there are
      quite a few distinct use cases involving device dependencies, they
      are relatively hard to get right in a driver (if one wants to
      address all of them properly) and it only gets worse if multiplied
      by the number of drivers potentially needing to do it.  Morever, at
      least one case (asynchronous system suspend/resume) cannot be handled
      in a single driver at all, because it requires the driver of A to
      wait for B to suspend (during system suspend) and the driver of B to
      wait for A to resume (during system resume).
      
      For this reason, represent dependencies between devices as "links",
      with the help of struct device_link objects each containing pointers
      to the "linked" devices, a list node for each of them, status
      information, flags, and an RCU head for synchronization.
      
      Also add two new list heads, representing the lists of links to the
      devices that depend on the given one (consumers) and to the devices
      depended on by it (suppliers), and a "driver presence status" field
      (needed for figuring out initial states of device links) to struct
      device.
      
      The entire data structure consisting of all of the lists of link
      objects for all devices is protected by a mutex (for link object
      addition/removal and for list walks during device driver probing
      and removal) and by SRCU (for list walking in other case that will
      be introduced by subsequent change sets).  If CONFIG_SRCU is not
      selected, however, an rwsem is used for protecting the entire data
      structure.
      
      In addition, each link object has an internal status field whose
      value reflects whether or not drivers are bound to the devices
      pointed to by the link or probing/removal of their drivers is in
      progress etc.  That field is only modified under the device links
      mutex, but it may be read outside of it in some cases (introduced by
      subsequent change sets), so modifications of it are annotated with
      WRITE_ONCE().
      
      New links are added by calling device_link_add() which takes three
      arguments: pointers to the devices in question and flags.  In
      particular, if DL_FLAG_STATELESS is set in the flags, the link status
      is not to be taken into account for this link and the driver core
      will not manage it.  In turn, if DL_FLAG_AUTOREMOVE is set in the
      flags, the driver core will remove the link automatically when the
      consumer device driver unbinds from it.
      
      One of the actions carried out by device_link_add() is to reorder
      the lists used for device shutdown and system suspend/resume to
      put the consumer device along with all of its children and all of
      its consumers (and so on, recursively) to the ends of those lists
      in order to ensure the right ordering between all of the supplier
      and consumer devices.
      
      For this reason, it is not possible to create a link between two
      devices if the would-be supplier device already depends on the
      would-be consumer device as either a direct descendant of it or a
      consumer of one of its direct descendants or one of its consumers
      and so on.
      
      There are two types of link objects, persistent and non-persistent.
      The persistent ones stay around until one of the target devices is
      deleted, while the non-persistent ones are removed automatically when
      the consumer driver unbinds from its device (ie. they are assumed to
      be valid only as long as the consumer device has a driver bound to
      it).  Persistent links are created by default and non-persistent
      links are created when the DL_FLAG_AUTOREMOVE flag is passed
      to device_link_add().
      
      Both persistent and non-persistent device links can be deleted
      with an explicit call to device_link_del().
      
      Links created without the DL_FLAG_STATELESS flag set are managed
      by the driver core using a simple state machine.  There are 5 states
      each link can be in: DORMANT (unused), AVAILABLE (the supplier driver
      is present and functional), CONSUMER_PROBE (the consumer driver is
      probing), ACTIVE (both supplier and consumer drivers are present and
      functional), and SUPPLIER_UNBIND (the supplier driver is unbinding).
      The driver core updates the link state automatically depending on
      what happens to the linked devices and for each link state specific
      actions are taken in addition to that.
      
      For example, if the supplier driver unbinds from its device, the
      driver core will also unbind the drivers of all of its consumers
      automatically under the assumption that they cannot function
      properly without the supplier.  Analogously, the driver core will
      only allow the consumer driver to bind to its device if the
      supplier driver is present and functional (ie. the link is in
      the AVAILABLE state).  If that's not the case, it will rely on
      the existing deferred probing mechanism to wait for the supplier
      driver to become available.
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      9ed98953
  17. 31 8月, 2016 2 次提交
  18. 07 12月, 2015 1 次提交
  19. 18 10月, 2015 1 次提交
  20. 18 9月, 2015 1 次提交
  21. 06 8月, 2015 1 次提交
    • G
      driver core: correct device's shutdown order · 52cdbdd4
      Grygorii Strashko 提交于
      Now device's shutdown sequence is performed in reverse order of their
      registration in devices_kset list and this sequence corresponds to the
      reverse device's creation order. So, devices_kset data tracks
      "parent<-child" device's dependencies only.
      
      Unfortunately, that's not enough and causes problems in case of
      implementing board's specific shutdown procedures. For example [1]:
      "DRA7XX_evm uses PCF8575 and one of the PCF output lines feeds to
      MMC/SD and this line should be driven high in order for the MMC/SD to
      be detected. This line is modelled as regulator and the hsmmc driver
      takes care of enabling and disabling it. In the case of 'reboot',
      during shutdown path as part of it's cleanup process the hsmmc driver
      disables this regulator. This makes MMC boot not functional."
      
      To handle this issue the .shutdown() callback could be implemented
      for PCF8575 device where corresponding GPIO pins will be configured to
      states, required for correct warm/cold reset. This can be achieved
      only when all .shutdown() callbacks have been called already for all
      PCF8575's consumers. But devices_kset is not filled correctly now:
      
      devices_kset: Device61 4e000000.dmm
      devices_kset: Device62 48070000.i2c
      devices_kset: Device63 48072000.i2c
      devices_kset: Device64 48060000.i2c
      devices_kset: Device65 4809c000.mmc
      ...
      devices_kset: Device102 fixedregulator-sd
      ...
      devices_kset: Device181 0-0020 // PCF8575
      devices_kset: Device182 gpiochip496
      devices_kset: Device183 0-0021 // PCF8575
      devices_kset: Device184 gpiochip480
      
      As can be seen from above .shutdown() callback for PCF8575 will be called
      before its consumers, which, in turn means, that any changes of PCF8575
      GPIO's pins will be or unsafe or overwritten later by GPIO's consumers.
      The problem can be solved if devices_kset list will be filled not only
      according device creation order, but also according device's probing
      order to track "supplier<-consumer" dependencies also.
      
      Hence, as a fix, lets add devices_kset_move_last(),
      devices_kset_move_before(), devices_kset_move_after() and call them
      from device_move() and also add call of devices_kset_move_last() in
      really_probe(). After this change all entries in devices_kset will
      be sorted according to device's creation ("parent<-child") and
      probing ("supplier<-consumer") order.
      
      devices_kset after:
      devices_kset: Device121 48070000.i2c
      devices_kset: Device122 i2c-0
      ...
      devices_kset: Device147 regulator.24
      devices_kset: Device148 0-0020
      devices_kset: Device149 gpiochip496
      devices_kset: Device150 0-0021
      devices_kset: Device151 gpiochip480
      devices_kset: Device152 0-0019
      ...
      devices_kset: Device372 fixedregulator-sd
      devices_kset: Device373 regulator.29
      devices_kset: Device374 4809c000.mmc
      devices_kset: Device375 mmc0
      
      [1] http://www.spinics.net/lists/linux-mmc/msg29825.html
      
      Cc: Sekhar Nori <nsekhar@ti.com>
      Signed-off-by: NGrygorii Strashko <grygorii.strashko@ti.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      52cdbdd4
  22. 28 7月, 2015 1 次提交
  23. 23 7月, 2015 1 次提交
  24. 26 6月, 2015 1 次提交
  25. 04 4月, 2015 1 次提交
    • R
      device property: Make it possible to use secondary firmware nodes · 97badf87
      Rafael J. Wysocki 提交于
      Add a secondary pointer to struct fwnode_handle so as to make it
      possible for a device to have two firmware nodes associated with
      it at the same time, for example, an ACPI node and a node with
      a set of properties provided by platform initialization code.
      
      In the future that will allow device property lookup to fall back
      from the primary firmware node to the secondary one if the given
      property is not present there to make it easier to provide defaults
      for device properties used by device drivers.
      
      Introduce two helper routines, set_primary_fwnode() and
      set_secondary_fwnode() allowing callers to add a primary/secondary
      firmware node to the given device in such a way that
      
       (1) If there's only one firmware node for that device, it will be
           pointed to by the device's firmware node pointer.
       (2) If both the primary and secondary firmware nodes are present,
           the primary one will be pointed to by the device's firmware
           node pointer, while the secondary one will be pointed to by the
           primary node's secondary pointer.
       (3) If one of these nodes is removed (by calling one of the new
           nelpers with NULL as the second argument), the other one will
           be preserved.
      
      Make ACPI use set_primary_fwnode() for attaching its firmware nodes
      to devices.
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Tested-by: NHeikki Krogerus <heikki.krogerus@linux.intel.com>
      Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      97badf87
  26. 25 3月, 2015 2 次提交
  27. 27 1月, 2015 1 次提交
  28. 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
  29. 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
  30. 24 9月, 2014 1 次提交
  31. 17 4月, 2014 1 次提交
  32. 26 3月, 2014 1 次提交
  33. 10 3月, 2014 1 次提交
  34. 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