linux-kernel - Re: [PATCH v2] block/mq-deadline: adjust the timeout period of the per

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: <8406f13d-d8be-4957-b1ec-6996f19d32e9@acm.org>
Date: Thu, 9 Oct 2025 16:40:16 -0700
From: Bart Van Assche <bvanassche@....org>
To: Damien Le Moal <dlemoal@...nel.org>, chengkaitao <pilgrimtao@...il.com>,
 axboe@...nel.dk
Cc: linux-block@...r.kernel.org, linux-kernel@...r.kernel.org,
 Chengkaitao <chengkaitao@...inos.cn>
Subject: Re: [PATCH v2] block/mq-deadline: adjust the timeout period of the
 per_prio->dispatch


On 10/9/25 1:21 PM, Damien Le Moal wrote:
> There is still something bothering me with this: the request is added to the
> dispatch list, and *NOT* to the fifo/sort list. So this should be considered as
> a scheduling decision in itself, and __dd_dispatch_request() reflects that as
> the first thing it does is pick the requests that are in the dispatch list
> already. However, __dd_dispatch_request() also has the check:
> 
> 		if (started_after(dd, rq, latest_start))
>                          return NULL;
> 
> for requests that are already in the dispatch list. That is what does not make
> sense to me. Why ? There is no comment describing this. And I do not understand
> why we should bother with any time for requests that are in the dispatch list
> already. These should be sent to the drive first, always.
> 
> This patch seems to be fixing a problem that is introduced by the above check.
> But why this check ? What am I missing here ?

Is my conclusion from the above correct that there is agreement that the 
I/O priority should be ignored for AT HEAD requests and that AT HEAD
requests should always be dispatched first? If so, how about merging the
three per I/O priority dispatch lists into a single dispatch list and
not to call started_after() at all for the dispatch list?

Thanks,

Bart.