linux-kernel - Re: [RFC PATCH] blk-mq: Clean up references when freeing rqs

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]

Date:   Wed, 9 Dec 2020 09:55:30 +0000
From:   John Garry <john.garry@...wei.com>
To:     Ming Lei <ming.lei@...hat.com>
CC:     <axboe@...nel.dk>, <linux-block@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>, <hch@....de>, <hare@...e.de>,
        <ppvk@...eaurora.org>, <bvanassche@....org>,
        <kashyap.desai@...adcom.com>
Subject: Re: [RFC PATCH] blk-mq: Clean up references when freeing rqs

On 09/12/2020 01:01, Ming Lei wrote:
> blk_mq_queue_tag_busy_iter() can be run on another request queue just
> between one driver tag is allocated and updating the request map, so one
> extra request reference still can be grabbed.
> 
> So looks only holding one queue's usage_counter doesn't help this issue, since
> bt_for_each() always iterates on driver tags wide.
> 
>> But I didn't see such a guard for blk_mq_tagset_busy_iter().
> IMO there isn't real difference between the two iteration.

ok, I see. Let me try to recreate that one, which will prob again 
require artificial delays added.

Apart from this, my concern is that we come with for a solution, but 
it's a complicated solution and may not be accepted as this issue is not 
seen as a problem in practice.

Thanks,
John