On 10 May 2016 at 11:07, Adrian Hunter <adrian.hunter@xxxxxxxxx> wrote: > 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. You are right, I will put this patch on hold! Thanks! I need to change the validation for this special SDIO case first. We shouldn't need to detach the bus and thus also remove the card in these cases, but instead only remove the SDIO func devices. Kind regards Uffe -- 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
