linux-kernel - Re: [PATCH] mmc: core: Remove timeout when enabling cache

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]

Date:   Tue, 20 Nov 2018 10:24:53 +0100
From:   Ulf Hansson <ulf.hansson@...aro.org>
To:     Wolfram Sang <wsa@...-dreams.de>, Faiz Abbas <faiz_abbas@...com>,
        Sjoerd Simons <sjoerd.simons@...labora.co.uk>
Cc:     "linux-mmc@...r.kernel.org" <linux-mmc@...r.kernel.org>,
        kernel@...labora.com,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Hongjie Fang <hongjiefang@...micro.com>,
        Bastian Stender <bst@...gutronix.de>,
        Kyle Roeschley <kyle.roeschley@...com>,
        Wolfram Sang <wsa+renesas@...g-engineering.com>,
        Shawn Lin <shawn.lin@...k-chips.com>,
        Harish Jenny K N <harish_kandiga@...tor.com>,
        Simon Horman <horms+renesas@...ge.net.au>
Subject: Re: [PATCH] mmc: core: Remove timeout when enabling cache

On 7 November 2018 at 09:47, Wolfram Sang <wsa@...-dreams.de> wrote:
>
>> That also happens to be one of the cards we deploy; However i did
>> wonder about adding a quirk but decided against it as it was not clear
>> to me from the specification that CACHE ON really is meant to complete
>> within GENERIC_CMD6_TIMEOUT. That and i fret about ending up in hit-a-
>> mole games as the failure is really quite tedious (boot failure).
>
> I agree that we should use the more defensive variant as a default. I
> mean there should be no performance regression since most cards will
> respond just faster, or? The only downside I could see is that we might
> miss a real timeout with no bounds set and might get stuck?

Well, you have a point, but still it's kind of nice to know which
cards are behaving well and which ones that doesn't. Hence I think I
prefer to stick using a quirk, unless you have a strong opinion.

Note that, in this case we can use CMD13 to poll for busy, which then
means it also works for those hosts that doesn't support HW busy
detection, without getting additional delays. If this hasn't been the
case, we must be using a quirk, but now we are more free to choose.

> Maybe it is
> worth contacting eMMC spec people to at least know what is the expected
> behaviour?

According to the spec, the GENERIC_CMD6_TIMEOUT should be sufficient.
So this card is not conforming to the spec, I think it's as simple as
that.

Kind regards
Uffe