linux-kernel - Re: LKFT: arm x15: mmc1: cache flush error -110

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: <0963b60f-15e7-4bc6-10df-6fc8003e4d42@nvidia.com>
Date:   Tue, 25 Feb 2020 16:24:38 +0000
From:   Jon Hunter <jonathanh@...dia.com>
To:     Ulf Hansson <ulf.hansson@...aro.org>,
        Faiz Abbas <faiz_abbas@...com>,
        Sowjanya Komatineni <skomatineni@...dia.com>
CC:     Bitan Biswas <bbiswas@...dia.com>,
        Adrian Hunter <adrian.hunter@...el.com>,
        Naresh Kamboju <naresh.kamboju@...aro.org>,
        "Jens Axboe" <axboe@...nel.dk>,
        Alexei Starovoitov <ast@...nel.org>,
        linux-block <linux-block@...r.kernel.org>,
        <lkft-triage@...ts.linaro.org>,
        open list <linux-kernel@...r.kernel.org>,
        "linux-mmc@...r.kernel.org" <linux-mmc@...r.kernel.org>,
        Arnd Bergmann <arnd@...db.de>,
        John Stultz <john.stultz@...aro.org>,
        Thierry Reding <treding@...dia.com>
Subject: Re: LKFT: arm x15: mmc1: cache flush error -110


On 25/02/2020 14:26, Ulf Hansson wrote:

...

> However, from the core point of view, the response is still requested,
> only that we don't want the driver to wait for the card to stop
> signaling busy. Instead we want to deal with that via "polling" from
> the core.
> 
> This is a rather worrying behaviour, as it seems like the host driver
> doesn't really follow this expectations from the core point of view.
> And mmc_flush_cache() is not the only case, as we have erase, bkops,
> sanitize, etc. Are all these working or not really well tested?

I don't believe that they are well tested. We have a simple test to
mount an eMMC partition, create a file, check the contents, remove the
file and unmount. The timeouts always occur during unmounting.

> Earlier, before my three patches, if the provided timeout_ms parameter
> to __mmc_switch() was zero, which was the case for
> mmc_mmc_flush_cache() - this lead to that __mmc_switch() simply
> ignored validating host->max_busy_timeout, which was wrong. In any
> case, this also meant that an R1B response was always used for
> mmc_flush_cache(), as you also indicated above. Perhaps this is the
> critical part where things can go wrong.
> 
> BTW, have you tried erase commands for sdhci tegra driver? If those
> are working fine, do you have any special treatments for these?

That I am not sure, but I will check.

Cheers
Jon

-- 
nvpublic