Revert "driver core: synchronize device shutdown"
PATCH 1/1 Revert "driver core: synchronize device shutdown"
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.
--- drivers/base/core.c | 2 -- 1 file changed, 2 deletions(-)
drivers/base/core.c +0 -2
@@ -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 (); }/*
Signature · 1 line
1.9.0
Greg Kroah-Hartman
maintainerQuoted 23 lines · Roland Dreier
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()indevice_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.
Quoted 6 lines
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]>
Hm, no one seems to have said anything for the past 5 years about this.
Shaohua and Arjan, any objection to this being applied?
thanks,
greg k-h
Quoted 1 line
Hm, no one seems to have said anything for the past 5 years about this.
It definitely is hard to hit -- you have to do "shutdown" or "reboot" right as something schedules async work. In our case we have some systems with a large and slightly flaky SAS fabric, so there's a constant level of re-probing SCSI disks, and we occasionally see reboots hanging due to waiting for never-finishing sd probe async work.
AFAICT the synchronization does nothing useful and is just a remnant of a patch series where the real meat didn't get applied. But of course it would be great if Shaohua could confirm my understanding.
Thanks,
Roland
Greg Kroah-Hartman
maintainerQuoted 9 lines · Roland Dreier
Quoted 1 line
Hm, no one seems to have said anything for the past 5 years about this.
It definitely is hard to hit -- you have to do "shutdown" or "reboot" right as something schedules async work. In our case we have some systems with a large and slightly flaky SAS fabric, so there's a constant level of re-probing SCSI disks, and we occasionally see reboots hanging due to waiting for never-finishing sd probe async work.
Quoted 3 lines
AFAICT the synchronization does nothing useful and is just a remnant of a patch series where the real meat didn't get applied. But of course it would be great if Shaohua could confirm my understanding.
Shaohua's email address seems to now bounce :(
Arjan, any thoughts?
greg k-h
Quoted 7 lines
Quoted 3 lines
AFAICT the synchronization does nothing useful and is just a remnant of a patch series where the real meat didn't get applied. But of course it would be great if Shaohua could confirm my understanding.
Shaohua's email address seems to now bounce :(
Arjan, any thoughts?
if there are no users, it should go... all it does it slows down the shutdown.
Greg Kroah-Hartman
maintainerQuoted 10 lines · Arjan van de Ven
Quoted 7 lines
Quoted 3 lines
AFAICT the synchronization does nothing useful and is just a remnant of a patch series where the real meat didn't get applied. But of course it would be great if Shaohua could confirm my understanding.
Shaohua's email address seems to now bounce :(
Arjan, any thoughts?
if there are no users, it should go... all it does it slows down the shutdown.
Ok, thanks, will revert it.