[PATCH v2 0/4] fix / cleanup async scsi scanning

[Dan Williams]

Commit a7a20d10 "[SCSI] sd: limit the scope of the async probe domain"
introduces a boot regression by moving sd probe work off of the global
async queue.  Using a local async domain hides the probe work from being
synchronized by wait_for_device_probe()->async_synchronize_full().

Fix this by teaching async_synchronize_full() to flush all async work
regardless of domain, and take the opportunity to convert scsi scanning
to async_schedule().  This enables wait_for_device_probe() to flush scsi
scanning work.

Changes since v1: http://marc.info/?l=linux-scsi&m=133793153025832&w=2

1/ Tested to fix the boot hang that Meelis reported with v1.  Reworked
   async_synchronize_full() to walk through all the active domains,
   otherwise we spin on !list_empty(async_domains) and prevent the async
   context from running.

2/ Added the ability for domains to opt-out of global syncing as
   requested by Arjan, but also needed for domains that don't want to worry
   about list corruption when the domain goes out of scope (stack-allocated
   domains).

---

Dan Williams (4):
      async: introduce 'async_domain' type
      async: make async_synchronize_full() flush all work regardless of domain
      scsi: queue async scan work to an async_schedule domain
      scsi: cleanup usages of scsi_complete_async_scans


 drivers/regulator/core.c      |    2 +
 drivers/scsi/libsas/sas_ata.c |    2 +
 drivers/scsi/scsi.c           |    4 ++
 drivers/scsi/scsi_priv.h      |    3 +-
 drivers/scsi/scsi_scan.c      |   24 +++----------
 drivers/scsi/scsi_wait_scan.c |   15 +++-----
 include/linux/async.h         |   36 +++++++++++++++++--
 include/scsi/scsi_scan.h      |   11 ------
 kernel/async.c                |   76 +++++++++++++++++++++++++++++++----------
 kernel/power/hibernate.c      |    8 ----
 kernel/power/user.c           |    2 -
 11 files changed, 107 insertions(+), 76 deletions(-)
 delete mode 100644 include/scsi/scsi_scan.h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/