[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <3aee8ffe-d8c6-71b2-8725-028406efef5c@huawei.com>
Date: Tue, 14 Jun 2022 10:29:16 +0100
From: John Garry <john.garry@...wei.com>
To: Christoph Hellwig <hch@....de>
CC: <axboe@...nel.dk>, <damien.lemoal@...nsource.wdc.com>,
<jejb@...ux.ibm.com>, <martin.petersen@...cle.com>,
<brking@...ibm.com>, <hare@...e.de>, <linux-block@...r.kernel.org>,
<linux-ide@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
<linux-scsi@...r.kernel.org>, <chenxiang66@...ilicon.com>
Subject: Re: [PATCH RFC v2 01/18] blk-mq: Add a flag for reserved requests
On 14/06/2022 07:43, Christoph Hellwig wrote:
> On Thu, Jun 09, 2022 at 06:29:02PM +0800, John Garry wrote:
>> Add a flag for reserved requests so that drivers may know this for any
>> special handling.
>>
>> The 'reserved' argument in blk_mq_ops.timeout callback could now be
>> replaced by using this flag.
> And we should probably do that ASAP, independent of the rest of this
> series.
We only have 2x users of the 'reserved' arg for 11x implementations of
blk_mq_ops.timeout:
- mtip32xx.c
- scsi_lib.c
scsi_lib.c is dubious as currently scsi does use reserved commands. So
we really only have 1x.
I'd be happy to take any spin-off series to make this one more
manageable, but is just removing an arg a strong enough reason for that?
That reserved arg is passed around a lot in the blk-mq iter functions,
so probably yes.
> Otherwise looks good:
>
> Reviewed-by: Christoph Hellwig<hch@....de>
Thanks
Powered by blists - more mailing lists