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:   Wed, 25 Jan 2017 09:13:35 -0700
From:   Jens Axboe <>
To:     Paolo Valente <>
CC:     Jens Axboe <>, <>,
        Linux-Kernal <>,
        Omar Sandoval <>,
        Linus Walleij <>,
        Ulf Hansson <>,
        Mark Brown <>
Subject: Re: [PATCHSET v4] blk-mq-scheduling framework

On 01/25/2017 01:46 AM, Paolo Valente wrote:
>> Il giorno 23 gen 2017, alle ore 18:42, Jens Axboe <> ha scritto:
>> On 01/23/2017 10:04 AM, Paolo Valente wrote:
>>>> Il giorno 18 gen 2017, alle ore 17:21, Jens Axboe <> ha scritto:
>>>> On 01/18/2017 08:14 AM, Paolo Valente wrote:
>>>>> according to the function blk_mq_sched_put_request, the
>>>>> mq.completed_request hook seems to always be invoked (if set) for a
>>>>> request for which the mq.put_rq_priv is invoked (if set).
>>>> Correct, any request that came out of blk_mq_sched_get_request()
>>>> will always have completed called on it, regardless of whether it
>>>> had IO started on it or not.
>>> It seems that some request, after being dispatched, happens to have no
>>> mq.put_rq_priv invoked on it now or then.  Is it expected?  If it is,
>>> could you point me to the path through which the end of the life of
>>> such a request is handled?
>> I'm guessing that's a flush request. I added RQF_QUEUED to check for
>> that, if RQF_QUEUED is set, you know it has come from your get_request
>> handler.
> Exactly, the completion-without-put_rq_priv pattern seems to occur
> only for requests coming from the flusher, precisely because they have
> the flag RQF_ELVPRIV unset.  Just to understand: why is this flag
> unset for these requests, if they do have private elevator (bfq)
> data attached?  What am I misunderstanding?
> Just to be certain: this should be the only case where the
> completed_request hook is invoked while the put_rq_priv is not, right?

They must NOT have scheduler data attached. In your get_request
function, you must bypass if blk_mq_sched_bypass_insert() returns true.
See how mq-deadline does that. This is important, or you will get hangs
with flushes as well, since the IO scheduler private data and the flush
data is unionized in the request.

Jens Axboe

Powered by blists - more mailing lists