linux-kernel - Re: [PATCH v6 6/8] mq-deadline: covert to use request_queue->async

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: <1c2e8761-5344-4300-a2bf-9e80b3983968@fnnas.com>
Date: Fri, 21 Nov 2025 20:28:36 +0800
From: "Yu Kuai" <yukuai@...as.com>
To: "Hannes Reinecke" <hare@...e.de>, <axboe@...nel.dk>, 
	<nilay@...ux.ibm.com>, <bvanassche@....org>, 
	<linux-block@...r.kernel.org>, <linux-kernel@...r.kernel.org>, 
	"Yu Kuai" <yukuai@...as.com>
Subject: Re: [PATCH v6 6/8] mq-deadline: covert to use request_queue->async_depth

Hi,

在 2025/11/21 15:18, Hannes Reinecke 写道:
> ... and this is now the opposite. We are removing an existing attribute
> (raising questions about userland ABI stability).
> Wouldn't it be better to use the generic infrastructure (ie having a
> per-request queue async_depth variable), but keep the per-elevator
> sysfs attributes (which then just would display the per-queue variable).
>
The problem is we can't make this api inside elevator writable as it
used to be, and if user do use this, they will probably write it to
limit async requests.

And I feel it will be acceptable for this kind of user api compatibility,
replace it elsewhere with the same functionality when kernel version is
updated.

> That way we won't break userland and get around the awkward issue
> of presenting a dummy attribute when no elevator is loaded. 

-- 
Thanks,
Kuai