lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CACRpkdayGkuJE9z+QT41ZVoJJN4sBx4e28c5OLzC9obvE94gBw@mail.gmail.com>
Date:   Thu, 11 Mar 2021 02:01:57 +0100
From:   Linus Walleij <linus.walleij@...aro.org>
To:     Ulf Hansson <ulf.hansson@...aro.org>
Cc:     linux-mmc <linux-mmc@...r.kernel.org>,
        "Rafael J . Wysocki" <rjw@...ysocki.net>,
        Kiwoong Kim <kwmad.kim@...sung.com>,
        Adrian Hunter <adrian.hunter@...el.com>,
        Wolfram Sang <wsa+renesas@...g-engineering.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Linux PM list <linux-pm@...r.kernel.org>,
        Android Kernel Team <kernel-team@...roid.com>,
        stable <stable@...r.kernel.org>
Subject: Re: [PATCH] mmc: core: Fix hanging on I/O during system suspend for
 removable cards

On Wed, Mar 10, 2021 at 4:29 PM Ulf Hansson <ulf.hansson@...aro.org> 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.
>
> Moreover, to allow and SDIO card to be removed during system suspend, let's
> manage this from a ->prepare() callback, assigned at the mmc_host_class
> level. In this way, we can use the parent device (the mmc_host_class
> device), to remove the card device that is the child, in the
> device_prepare() phase.
>
> Reported-by: Kiwoong Kim <kwmad.kim@...sung.com>
> Cc: stable@...r.kernel.org
> Signed-off-by: Ulf Hansson <ulf.hansson@...aro.org>

This makes sense to me.
Reviewed-by: Linus Walleij <linus.walleij@...aro.org>

Yours,
Linus Walleij

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ