> 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. Okay and I'll also thing about its fix. Thanks. Kiwoong Kim > > [...] > > Kind regards > Uffe
