On Mon, 15 Mar 2021 at 06:46, Kiwoong Kim <kwmad.kim@xxxxxxxxxxx> wrote: > > > The mmc core uses a PM notifier to temporarily during system suspend, turn > > off the card detection mechanism for removal/insertion of (e)MMC/SD/SDIO > > cards. Additionally, the notifier may be used to remove an SDIO card > > entirely, if a corresponding SDIO functional driver don't have the system > > suspend/resume callbacks assigned. This behaviour has been around for a > > very long time. > > > > However, a recent bug report tells us there are problems with this > > approach. More precisely, when receiving the PM_SUSPEND_PREPARE > > notification, we may end up hanging on I/O to be completed, thus also > > preventing the system from getting suspended. > > > > In the end what happens, is that the cancel_delayed_work_sync() in > > mmc_pm_notify() ends up waiting for mmc_rescan() to complete - and since > > mmc_rescan() wants to claim the host, it needs to wait for the I/O to be > > completed first. > > > > Typically, this problem is triggered in Android, if there is ongoing I/O > > while the user decides to suspend, resume and then suspend the system > > again. This due to that after the resume, an mmc_rescan() work gets punted > > to the workqueue, which job is to verify that the card remains inserted > > after the system has resumed. > > > > To fix this problem, userspace needs to become frozen to suspend the I/O, > > prior to turning off the card detection mechanism. Therefore, let's drop > > the PM notifiers for mmc subsystem altogether and rely on the card > > detection to be turned off/on as a part of the system_freezable_wq, that > > we are already using. > > > Dear Ulf > > Do you think there is no possibility that claiming a host by mmc_rescan is > postponed by early IO requests? > E.g. the case where the work is executed later unexpectedly for something. That shouldn't matter. The important part is that I/O from userspace gets suspended before the system_freezable_wq gets frozen, which is what mmc_rescan() runs from. > > And it seems that cancelling the work before system suspend is removed in > the patch. > That means you might think there is no case with the pended the work, I > think. > Am I right? When system_freezable_wq is frozen, running works will be synced for completion. Scheduled works don't get to run until the system_freezable_wq is unfrozen. In other words, the behaviour remains the same, except that we are suspending card detection in mmc_rescan() to a slightly later state. > > If I mis-understand something, please let me know. > > Thanks. > Kiwoong Kim > Did you try out the patch at your side, to see if it resolves your problems? Kind regards Uffe
