linux-kernel - Re: [PATCH v1] blk-mq: add one blk_mq_req_flags

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <1a948684-aa1a-46cb-a51b-e16b1da1c358@grimberg.me>
Date: Wed, 23 Oct 2024 12:42:46 +0300
From: Sagi Grimberg <sagi@...mberg.me>
To: Christoph Hellwig <hch@....de>
Cc: Ming Lei <ming.lei@...hat.com>, zhuxiaohui <zhuxiaohui400@...il.com>,
 axboe@...nel.dk, kbusch@...nel.org, linux-block@...r.kernel.org,
 linux-kernel@...r.kernel.org, linux-nvme@...ts.infradead.org,
 Zhu Xiaohui <zhuxiaohui.400@...edance.com>
Subject: Re: [PATCH v1] blk-mq: add one blk_mq_req_flags_t type to support mq
 ctx fallback




On 23/10/2024 8:19, Christoph Hellwig wrote:
> On Tue, Oct 22, 2024 at 04:23:29PM +0300, Sagi Grimberg wrote:
>> I agree. NVMe may have a unique need here, but it needs a tag from a
>> specific hctx while the context requesting it does not map according to
>> the hctx cpumap. It cannot use any other tag from any other hctx.
>>
>> The reason is that the connect for a queue must be done from a tag that
>> belongs to the queue because nvme relies on it when it does resolution back
>> to
>> the request to the completion.
> I wonder if we should byte the bullet and not use a request for the
> connect commands.  We've already special cased the AEN command because
> it was causing too many problems, and given all the pain so far connect
> might also have hit that treshold.

That would be trading one set of problems for another. We had some hard
times in the past to correctly fence AERs against controller states 
because it
is not a normal block request.

Plus, unlike AERs, connect has a timeout, which we'll need to take care 
of...

Not that it is not possible, I'd just like to avoid this option.