linux-kernel - Re: [PATCH v4 1/4] block: Add iocontext priority to request

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: <89fb830f-d909-b2c3-e577-2fd18208b2ab@kernel.dk>
Date:   Thu, 13 Oct 2016 15:07:56 -0600
From:   Jens Axboe <axboe@...nel.dk>
To:     Dan Williams <dan.j.williams@...el.com>
Cc:     Adam Manzanares <adam.manzanares@...t.com>,
        Tejun Heo <tj@...nel.org>, Hannes Reinecke <hare@...e.de>,
        "Martin K. Petersen" <martin.petersen@...cle.com>,
        mchristi@...hat.com, Toshi Kani <toshi.kani@....com>,
        Ming Lei <ming.lei@...onical.com>, sathya.prakash@...adcom.com,
        chaitra.basappa@...adcom.com,
        suganath-prabu.subramani@...adcom.com, linux-block@...r.kernel.org,
        IDE/ATA development list <linux-ide@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        MPT-FusionLinux.pdl@...adcom.com,
        linux-scsi <linux-scsi@...r.kernel.org>,
        Adam Manzananares <adam.manzanares@....com>
Subject: Re: [PATCH v4 1/4] block: Add iocontext priority to request

On 10/13/2016 02:59 PM, Dan Williams wrote:
> On Thu, Oct 13, 2016 at 1:24 PM, Jens Axboe <axboe@...nel.dk> wrote:
>> On 10/13/2016 02:19 PM, Dan Williams wrote:
>>>
>>> On Thu, Oct 13, 2016 at 1:09 PM, Jens Axboe <axboe@...nel.dk> wrote:
>>>>
>>>> On 10/13/2016 02:06 PM, Dan Williams wrote:
>>>>>
>>>>>
>>>>> On Thu, Oct 13, 2016 at 12:53 PM, Adam Manzanares
>>>>> <adam.manzanares@...t.com> wrote:
>>>>>>
>>>>>>
>>>>>> Patch adds an association between iocontext ioprio and the ioprio of a
>>>>>> request. This value is set in blk_rq_set_prio which takes the request
>>>>>> and
>>>>>> the ioc as arguments. If the ioc is valid in blk_rq_set_prio then the
>>>>>> iopriority of the request is set as the iopriority of the ioc. In
>>>>>> init_request_from_bio a check is made to see if the ioprio of the bio
>>>>>> is
>>>>>> valid and if so then the request prio comes from the bio.
>>>>>>
>>>>>> Signed-off-by: Adam Manzananares <adam.manzanares@....com>
>>>>>> ---
>>>>>>  block/blk-core.c       |  4 +++-
>>>>>>  include/linux/blkdev.h | 14 ++++++++++++++
>>>>>>  2 files changed, 17 insertions(+), 1 deletion(-)
>>>>>>
>>>>>> diff --git a/block/blk-core.c b/block/blk-core.c
>>>>>> index 14d7c07..361b1b9 100644
>>>>>> --- a/block/blk-core.c
>>>>>> +++ b/block/blk-core.c
>>>>>> @@ -1153,6 +1153,7 @@ static struct request *__get_request(struct
>>>>>> request_list *rl, int op,
>>>>>>
>>>>>>         blk_rq_init(q, rq);
>>>>>>         blk_rq_set_rl(rq, rl);
>>>>>> +       blk_rq_set_prio(rq, ioc);
>>>>>>         req_set_op_attrs(rq, op, op_flags | REQ_ALLOCED);
>>>>>>
>>>>>>         /* init elvpriv */
>>>>>> @@ -1656,7 +1657,8 @@ void init_request_from_bio(struct request *req,
>>>>>> struct bio *bio)
>>>>>>
>>>>>>         req->errors = 0;
>>>>>>         req->__sector = bio->bi_iter.bi_sector;
>>>>>> -       req->ioprio = bio_prio(bio);
>>>>>> +       if (ioprio_valid(bio_prio(bio)))
>>>>>> +               req->ioprio = bio_prio(bio);
>>>>>
>>>>>
>>>>>
>>>>> Should we use ioprio_best() here?  If req->ioprio and bio_prio()
>>>>> disagree one side has explicitly asked for a higher priority.
>>>>
>>>>
>>>>
>>>> It's a good question - but if priority has been set in the bio, it makes
>>>> sense that that would take priority over the general setting for the
>>>> task/io context. So I think the patch is correct as-is.
>>>
>>>
>>> Assuming you always trust the kernel to know the right priority...
>>
>>
>> If it set it in the bio, it better know what it's doing. Besides,
>> there's nothing stopping the caller from checking the task priority when
>> it sets it. If we do ioprio_best(), then we are effectively preventing
>> anyone from submitting a bio with a lower priority than the task has
>> generally set.
>
> Ah, that makes sense.  Move the ioprio_best() decision out to whatever
> code is setting bio_prio() to allow for cases where the kernel knows
> best.

Yes, precisely.

-- 
Jens Axboe