linux-kernel - Re: [bug report] block: Non-NCQ commands will never be executed while fio is continuously running

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: <ZyOQWyyai2JkKyzy@ryzen>
Date: Thu, 31 Oct 2024 15:12:43 +0100
From: Niklas Cassel <cassel@...nel.org>
To: Damien Le Moal <dlemoal@...nel.org>
Cc: Yu Kuai <yukuai1@...weicloud.com>, yangxingui <yangxingui@...wei.com>,
	axboe@...nel.dk, John Garry <john.g.garry@...cle.com>,
	linux-block@...r.kernel.org, linux-kernel@...r.kernel.org,
	James.Bottomley@...senpartnership.com,
	"Martin K. Petersen" <martin.petersen@...cle.com>,
	"yukuai (C)" <yukuai3@...wei.com>,
	"yangerkun@...wei.com" <yangerkun@...wei.com>
Subject: Re: [bug report] block: Non-NCQ commands will never be executed
 while fio is continuously running

On Thu, Sep 19, 2024 at 04:14:15PM +0200, Damien Le Moal wrote:
> On 2024/09/19 14:26, Yu Kuai wrote:
> > 
> > Does libata return a specific value in this case? If so, maybe we can
> > stop other hctx untill this IO is handled.
> > 
> > For now, I think libata should use single hctx, it just doesn't support
> > multiple hctx yet.
> 
> libata does not care/know about hctx. It only issues commands to ATA devices,
> which always are single queue. And pure SATA adapters like AHCI are always
> single queue.
> 
> The issue at hand can happen only for libsas based SAS HBAs that have multiple
> command submission queues (with a shared tag set). Commands for the same device
> may end up being submitted through different queues, and when the submitted
> commands include a mix of NCQ and non-NCQ commands, the problem happens without
> libata being able to easily do anything about it, and not possible control
> possible at the scsi layer either since the commands submitted are SCSI (not yet
> translated to ATA commands) which do not have any NCQ/non-NCQ exclusion
> knowledge at all. NCQ is an ATA concept unknown to the scsi and block layer.
> 
> We (Niklas and I) are trying to find a solution, but that may not be within
> libata itself. It may need changes to libsas as well. Not sure yet. Still exploring.

Hello Xingui,

I send a proposed solution to this problem here:
https://lore.kernel.org/linux-ide/20241031140731.224589-4-cassel@kernel.org/

Please test and see if it addresses your problem.


Kind regards,
Niklas