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, 26 Oct 2017 16:25:15 +0200
From:   Linus Walleij <>
To:     Adrian Hunter <>
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 V12 0/5] mmc: Add Command Queue support

On Thu, Oct 26, 2017 at 3:49 PM, Adrian Hunter <> wrote:
> On 26/10/17 16:32, Linus Walleij wrote:

>> My patch series switches the stack around to make it possible
>> to do this. But it doesn't go the whole way to complete the requests
>> from interrupt context.
>> Since we have to send commands for retune etc request finalization
>> cannot easily be done from interrupt context.
> Re-tuning and background operations are rare and slow, so there is no reason
> to try to start them from interrupt context.

OK I will try to get them out of the way and see what happens,
hehe :)

What I mean is that we were checking - on every command -
if BKOPS or retune needs to happen. And then doing it. Thus
all was done in process context.

>> But I am thinking about testing to hack it
>> using some ugly approaches ... like assuming we don't need any
>> retune etc and just say all is fine and optimistically complete the
>> request directly in the interrupt handler if all was OK and wait
>> for errors to happen before retuning.
> It already works that way.  Re-tuning happens before you start a request.
> We prevent re-tuning in between dependent requests, like between starting a
> transfer and CMD13 polling for completion.

Ah that is what these if()s do ... right. I'll see if I can get around
this then.

Linus Walleij

Powered by blists - more mailing lists