[PATCH] Revert "driver core: synchronize device shutdown"

[PATCH] Revert "driver core: synchronize device shutdown"

[Roland Dreier]

From: Roland Dreier <roland@purestorage.com>

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 <roland@purestorage.com>
---
 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

Re: [PATCH] Revert "driver core: synchronize device shutdown"

[Greg Kroah-Hartman]

On Tue, Mar 04, 2014 at 07:57:51PM -0800, Roland Dreier wrote:
> From: Roland Dreier <roland@purestorage.com>
> 
> 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 <roland@purestorage.com>

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

Re: [PATCH] Revert "driver core: synchronize device shutdown"

[Roland Dreier]

> 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

Re: [PATCH] Revert "driver core: synchronize device shutdown"

[Greg Kroah-Hartman]

On Tue, Mar 04, 2014 at 08:15:36PM -0800, Roland Dreier wrote:
> > 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.

Shaohua's email address seems to now bounce :(

Arjan, any thoughts?

greg k-h

Re: [PATCH] Revert "driver core: synchronize device shutdown"

[Arjan van de Ven]

>> 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.

Re: [PATCH] Revert "driver core: synchronize device shutdown"

[Greg Kroah-Hartman]

On Fri, Mar 07, 2014 at 06:30:49PM -0800, Arjan van de Ven wrote:
> >> 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.