From: Roland Dreier <[email protected]>

This reverts commit 401097ea4b89846d66ac78f7f108d49c2e922d9c.  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: Roland Dreier <[email protected]>
---
 drivers/base/core.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/base/core.c b/drivers/base/core.c
index 2b567177ef78..afea3697fa2e 100644
--- a/drivers/base/core.c
+++ b/drivers/base/core.c
@@ -23,7 +23,6 @@
 #include <linux/genhd.h>
 #include <linux/kallsyms.h>
 #include <linux/mutex.h>
-#include <linux/async.h>
 #include <linux/pm_runtime.h>
 #include <linux/netdevice.h>
 #include <linux/sysfs.h>
@@ -2003,7 +2002,6 @@ void device_shutdown(void)
                spin_lock(&devices_kset->list_lock);
        }
        spin_unlock(&devices_kset->list_lock);
-       async_synchronize_full();
 }
 
 /*
-- 
1.9.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Reply via email to