linux-kernel - Re: [PATCH] blk-mq: Properly init bios from blk_mq_alloc_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] [day] [month] [year] [list]

Message-ID: <20221025123330.GB10715@lst.de>
Date:   Tue, 25 Oct 2022 14:33:30 +0200
From:   Christoph Hellwig <hch@....de>
To:     John Garry <john.garry@...wei.com>
Cc:     Ming Lei <ming.lei@...hat.com>, axboe@...nel.dk,
        linux-kernel@...r.kernel.org, linux-block@...r.kernel.org,
        hch@....de, Bart Van Assche <bvanassche@....org>
Subject: Re: [PATCH] blk-mq: Properly init bios from
 blk_mq_alloc_request_hctx()

On Tue, Oct 25, 2022 at 12:36:10PM +0100, John Garry wrote:
> The requirement is to send this abort command on same queue as erroneous 
> command to ensure that they do not race in HW submission, even though 
> chance of this is really tiny. Maybe we can make low-level driver wait 
> until erroneous command is really submitted to HW by checking HW register, 
> etc. before issuing abort on any HW queue (and so would not need 
> blk_mq_alloc_request_hctx() or similar).

I'm not sure this is a good idea.  I can think of all kinds of interfaces
that could have similar requirements that absolutely do make sense from
the hardware / firmware side.  So despite Ming not liking
blk_mq_alloc_request_hctx there is very little chance of it going away
and thus also very little need to avoid users as more will eventually
pop up if we want it or not.

> BTW, I would still like to fix blk_mq_alloc_request_hctx() to properly init 
> ->bio and other fields - ok?

Yes, it should behave the same blk_mq_alloc_request in that respect,
and we should just copy the assignments to bio, biotail, __sector
and __data_len from it as you did in your RFC patch.

>
> Thanks,
> John
---end quoted text---