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 17:33:03 +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 07/10] mmc: block: blk-mq: Add support for direct

On 09/11/17 14:34, Linus Walleij wrote:
> On Thu, Nov 9, 2017 at 8:27 AM, Adrian Hunter <> wrote:
>> On 08/11/17 11:28, Linus Walleij wrote:
>>> On Fri, Nov 3, 2017 at 2:20 PM, Adrian Hunter <> wrote:
>>>> For blk-mq, add support for completing requests directly in the ->done
>>>> callback. That means that error handling and urgent background operations
>>>> must be handled by recovery_work in that case.
>>>> Signed-off-by: Adrian Hunter <>
>>> I tried enabling this on my MMC host (mmci) but I got weird
>>> DMA error messages when I did.
>>> I guess this has not been tested on a non-DMA-coherent
>>> system?
>> I don't see what DMA-coherence has to do with anything.
>> Possibilities:
>>         - DMA unmapping doesn't work in an atomic context
>>         - requests' DMA operations have to be synchronized with each other
> So since MMCI need the post_req() hook called with
> an error code to properly tear down any DMA operations,
> I was worried that maybe your error path is not doing this
> (passing an error code or calling in the right order).
> I had a bunch of fallouts in my own patch set relating
> to that.
>>> I think I might be seeing this because the .pre and .post
>>> callbacks need to be strictly sequenced, and this is
>>> maybe not taken into account here?
>> I looked at mmci but that did not seem to be the case.
>>> Isn't there as risk
>>> that the .post callback of the next request is called before
>>> the .post callback of the previous request has returned
>>> for example?
>> Of course, the requests are treated as independent.  If the separate DMA
>> operations require synchronization, that is for the host driver to fix.
> They are treated as independent by the block layer but
> it is the subsystems duty to serialize them for the hardware,
> MMCI strictly requires that pre/post hooks per request
> happen in the right order, so if you have prepared a second
> request after submitting the first, and the first fails, you have
> to back out by unpreparing the second one before unpreparing
> the first. It is also the only host driver requireing to be passed
> an error code in the last parameter to the post hook in
> order to work properly.
> I think your patch set handles that nicely though, because I
> haven't seen any errors, it's just when we do this direct
> completion I see problems.

If a request gets an error, then we always do the post_req before starting
another request, so the driver can assume that the first request finished
successfully if it is asked to do post_req on the second request.  So the
driver does have enough information to keep the DMA unmapping in order if

Powered by blists - more mailing lists