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  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:   Thu, 9 Nov 2017 09:43:44 +0200
From:   Adrian Hunter <>
To:     Linus Walleij <>
Cc:     Ulf Hansson <>,
        linux-mmc <>,
        linux-block <>,
        linux-kernel <>,
        Bough Chen <>,
        Alex Lemberg <>,
        Mateusz Nowak <>,
        Yuliy Izrailov <>,
        Jaehoon Chung <>,
        Dong Aisheng <>,
        Das Asutosh <>,
        Zhangfei Gao <>,
        Sahitya Tummala <>,
        Harjani Ritesh <>,
        Venu Byravarasu <>,
        Shawn Lin <>,
        Christoph Hellwig <>
Subject: Re: [PATCH V13 10/10] mmc: block: blk-mq: Stop using legacy recovery

On 08/11/17 11:38, Linus Walleij wrote:
> On Fri, Nov 3, 2017 at 2:20 PM, Adrian Hunter <> wrote:
>> There are only a few things the recovery needs to do. Primarily, it just
>> needs to:
>>         Determine the number of bytes transferred
>>         Get the card back to transfer state
>>         Determine whether to retry
>> There are also a couple of additional features:
>>         Reset the card before the last retry
>>         Read one sector at a time
>> The legacy code spent much effort analyzing command errors, but commands
>> fail fast, so it is simpler just to give all command errors the same number
>> of retries.
>> Signed-off-by: Adrian Hunter <>
> I have nothing against the patch as such. In fact something
> like this makes a lot of sense (to me).
> But this just makes mmc_blk_rw_recovery() look really nice.
> And leaves a very ugly mmc_blk_issue_rw_rq() with the legacy
> error handling in-tree.
> The former function isn't even named with some *mq* infix
> making it clear that the new recovery path only happens
> in the MQ case.
> If newcomers read this code in the MMC stack they will
> just tear their hair, scream and run away. Even faster than
> before.
> How are they supposed to know which functions are used on
> which path? Run ftrace?

You're kidding me right?  You don't know how to find where a function used?

> This illustrates firmly why we need to refactor and/or kill off
> the old block layer interface *first* then add MQ on top.

No it doesn't!  You are playing games!  One function could be named
differently, so that is evidence the whole patch set should be ignored.

The old code is rubbish.  There is nothing worth keeping.  Churning it
around is a waste of everybody's time.  Review and test the new code.
Delete the old code.  Much much simpler!

Powered by blists - more mailing lists