linux-kernel - Re: [PATCH] mmc: core: Mark mmc_host device with pm_runtime_no

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] [day] [month] [year] [list]

Message-ID: <CAPDyKFqUhx8SmpXj=kmxzEKLWt4RU8rTxiiQgAXWX=fzmL=J0Q@mail.gmail.com>
Date:   Mon, 21 Jun 2021 11:20:36 +0200
From:   Ulf Hansson <ulf.hansson@...aro.org>
To:     chgokhl@....com
Cc:     linux-mmc <linux-mmc@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        kehuanlin@...hsemi.com
Subject: Re: [PATCH] mmc: core: Mark mmc_host device with pm_runtime_no_callbacks

On Mon, 21 Jun 2021 at 03:38, hieagle <chgokhl@...il.com> wrote:
>
> Sorry, I don't receive the reply email in my gmail.
>
> Normally the mmc_host's power.disable_depth is large than zero, the
> rpm_resume(mmc:0001) will not be called recursively for parent. This is
> the most case.
>
> Although the mmc class device never calls pm_runtime_enable() directly,
> there are still some cases as below to call pm_runtime_enable(), which
> may cause it's power.disable_depth decremented to zero.
>   case1: device_resume_early->pm_runtime_enable
>   case2: device_resume->pm_runtime_enable

Those calls to pm_runtime_enable() are in balance with previous calls
to __pm_runtime_disable and pm_runtime_disable(), in
__device_suspend() and __device_suspend_late().

In other words, the power.disable_depth is not being decremented to
zero in any of those above path, I think.

>
> Anything that can go wrong will go wrong. Unfortunately we meet the case.
> If you trigger to set the mmc_host's power.disable_depth value to zero
> after mmc suspended, you can find the issue.
>
> In our platform the mmc device's parent list is as below:
>      mmc0:0001->mmc_host mmc0->fa630000.mmc->soc.
> The rpm_resume call trace is as below in our scenario:
>
> rpm_resume(mmc0:0001)
> |
> if (!parent && dev->parent) //true
> if (!parent->power.disable_depth
>    && !parent->power.ignore_children) //true
> rpm_resume(parent, 0) --->  rpm_resume(mmc_host, 0)
> |                           |
> |                           callback = RPM_GET_CALLBACK(mmc_host, ...) = NULL
> |                           retval = rpm_callback(callback, mmc_host) = -ENOSYS
> |                           |
> |                           return retval = -ENOSYS
> if (retval) goto out; //skip rpm_callback()
> return retval = -ENOSYS
>
> The scenario is rare, but anything that can go wrong will go wrong.
> The patch can enhance the code to avoid this scenario.

Well, I am still not convinced as I don't see how the
power.disable_depth can ever reach zero.

If you could provide a stack-trace of when power.disable_depth reaches
zero, that would be helpful.

[...]

Kind regards
Uffe