linux-kernel - Re: [PATCH 4/6] elevator: factor elevator lock out of dispatch

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: <36056c2f-f0c3-5758-3848-ca06371a6241@huaweicloud.com>
Date: Wed, 23 Jul 2025 14:10:23 +0800
From: Yu Kuai <yukuai1@...weicloud.com>
To: Damien Le Moal <dlemoal@...nel.org>, Yu Kuai <yukuai1@...weicloud.com>,
 hare@...e.de, tj@...nel.org, josef@...icpanda.com, axboe@...nel.dk
Cc: cgroups@...r.kernel.org, linux-block@...r.kernel.org,
 linux-kernel@...r.kernel.org, yi.zhang@...wei.com, yangerkun@...wei.com,
 johnny.chenyi@...wei.com, "yukuai (C)" <yukuai3@...wei.com>
Subject: Re: [PATCH 4/6] elevator: factor elevator lock out of
 dispatch_request method

Hi,

在 2025/07/23 12:34, Damien Le Moal 写道:
> What about something like this:
> 1) Introduce the elevator common/generic lock (first part of patch 1 + middle
> of patch 4 squashed together)
> 2) Convert deadline to use elevator generic lock (second part of patch 1 + end
> of patch 4)
> 3) Convert bfq to use elevator generic lock (patch 3 + beginning of patch 4)
> 4) Patch 6
> 
> As for the ioc changes, they do not seem directly related to the elevator lock
> changes, but since the code may conflict, maybe bring them as prep patches at
> the beginning (0).

This sounds good. BTW, the ioc changes has to be in front of step 3), to
prevent queue_lock to be nested in elevator lock.

Thanks,
Kuai