On Tue, 9 Mar 2021 at 14:07, Ulf Hansson <ulf.hansson@xxxxxxxxxx> wrote: > > On Tue, 9 Mar 2021 at 05:11, Kiwoong Kim <kwmad.kim@xxxxxxxxxxx> wrote: > > > > Dear All > > > > I want to discuss about this topic with you guys. > > > > There is an application to put many IO requests to a SD card right after completion of system resume. > > Current MMC stack invokes mmc_rescan asynchronously for PM_POST_SUSPEND. > > As reported to me, there could be a race between an IO thread and the kworker for mmc_rescan, > > especially when the application mentioned before is installed and the function of mmc_rescan is run later than expected > > For a series of IO requests, mmc_rescan, particularily at __mmc_claim_host called in mmc_sd_detect, didn't acquire a host for longer than expected. > > That's not a problem, in general. > > As long as the card is inserted and functional, the I/O operations > should be completed successfully. It doesn't matter if mmc_rescan() is > waiting to claim the host, as it's not important that it gets to run > as long as the card remains inserted/functional. > > > > > Below is the call stacks shown after the symptom happened and the system tried to enter into suspend again. > > In this case, mmc pm notifier is called with PM_SUSPEND_PREPARE, so it waits for completion or cancelling the work for mmc_rescan. > > For the latency, mobile users can see black screen for a long time sometimes, even with pushing a power button to wake up the system. > > I think I understand what you are saying, but please correct me if I am wrong. > > The I/O requests keep flowing into the blk queue even after > PM_SUSPEND_PREPARE has been fired, thus preventing the earlier > scheduled mmc_rescan() from claiming the host? > > This sounds quite reasonable that it could happen, at least > theoretically. Although, I am a bit surprised that nobody has reported > about this problem, until now. The design in the mmc core, has > remained unchanged in regards to this behaviour, for a very very long > time. > > Let me try to reproduce the problem, I will get back to you soon. In > the meantime, I would also appreciate it if you could share, more > exactly, how to trigger this problem at your side. I have managed to reproduce the problem! Wow, I wonder how this could have slipped through without anybody reporting about this, until now. So, thanks for bringing this to my attention! My rough guess is that SD cards, used in these kinds of configurations (Android), are actually set to non removable. This would prevent mmc_rescan() from claiming the host. In any case, this needs to be fixed properly. I will continue to work on a solution and get back to you with a patch. [...] Kind regards Uffe
