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]

Message-ID: <20201210020745.GA1363446@T590>
Date:   Thu, 10 Dec 2020 10:07:45 +0800
From:   Ming Lei <ming.lei@...hat.com>
To:     John Garry <john.garry@...wei.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 Wed, Dec 09, 2020 at 09:55:30AM +0000, John Garry wrote:
> 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.

If that is the case, I'd suggest to consider the solution in the
following link:

https://lore.kernel.org/linux-block/20200820180335.3109216-1-ming.lei@redhat.com/

At least, the idea is simple, which can be extended to support allocate driver tags
request pool dynamically.


Thanks, 
Ming