On 10/05/16 12:01, Ulf Hansson wrote: > On 29 April 2016 at 20:40, Adrian Hunter <adrian.hunter@xxxxxxxxx> wrote: >> On 28/04/2016 9:29 p.m., Ulf Hansson wrote: >>> >>> For the reasons explained below, it's safe to remove the rescan_disable >>> flag. >>> >>> 1) >>> cancel_delayed_work_sync() prevents an executing work from re-scheduling >>> itself. >>> >>> 2) >>> We are using the system_freezable_wq for the rescan works. As that queue >>> becomes frozen when userspace becomes frozen during system PM, we don't >>> need to disable the rescan works in the PM_SUSPEND_PREPARE phase. >> >> >> What about the case when a SDIO card has to be removed? Seems like a rescan >> could theoretically get scheduled and run before the workqueue is frozen. > > When the queue gets frozen, it means currently running works will be > synced. Works that are scheduled (or becomes scheduled) will be put on > hold and not allowed to run before the workqueue becomes un-frozen. In the pm_notifier the workqueue is not frozen, so new work could be queued and run, which would potentially race with the "host->bus_ops->remove(host)" a few lines further on. -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
