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:   Tue, 26 Mar 2019 08:17:23 -0600
From:   Jens Axboe <>
To:     Hannes Reinecke <>,
        "" <>
Subject: Re: [PATCH V2 8/8] blk-mq: remove blk_mq_tagset_busy_iter

On 3/25/19 2:25 AM, Hannes Reinecke wrote:
> On 3/25/19 8:37 AM, wrote:
>> Hi Hannes
>> On 3/25/19 3:18 PM, Hannes Reinecke wrote:
>>> On 3/25/19 6:38 AM, Jianchao Wang wrote:
>>>> As nobody uses blk_mq_tagset_busy_iter, remove it.
>>>> Signed-off-by: Jianchao Wang <>
>>>> ---
>>>>    block/blk-mq-tag.c     | 95 --------------------------------------------------
>>>>    include/linux/blk-mq.h |  2 --
>>>>    2 files changed, 97 deletions(-)
>>> Please, don't.
>>> I'm currently implementing reserved commands for SCSI and reworking
>>> the SCSI error handling where I rely on this interface quite
>>> heavily.
>> blk_mq_tagset_busy_iter could access some stale requests which maybe
>> freed due to io scheduler switching, request_queue cleanup (shared
>> tagset) when there is someone submits io and gets driver tag. When io
>> scheduler attached, even quiesce request_queue won't work.
>> If this patchset is accepted, blk_mq_tagset_busy_iter could be
>> replaced with blk_mq_queue_inflight_tag_iter which needs to be
>> invoked by every request_queue that shares the tagset.
> The point is, at that time I do _not_ have a request queue to work
> with.
> Most SCSI drivers have a host-wide shared tagset, which is used by all
> request queues on that host.  Iterating over the shared tagset is far
> more efficient than to traverse over all devices and the attached
> request queues.
> If I had to traverse all request queues I would need to add additional
> locking to ensure this traversal is race-free, making it a really
> cumbersome interface to use.
> Plus the tagset iter is understood to be used only in cases where I/O
> is stopped from the upper layers (ie no new I/O will be submitted).
> So here we only need to protect against I/O being completed, which is
> not what this patchset is about.
> So my objection still stands: Please, don't.

We can't just keep an interface that's hard to use correctly just
because you have something pending for that. Jianchao has good
suggestions for you on how to proceed.

Jens Axboe

Powered by blists - more mailing lists