linux-kernel - Re: [PATCH v3 01/17] ext4: add ext4_try_lock

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: <aH_7ue3fNcLjzxYw@tassilo>
Date: Tue, 22 Jul 2025 13:59:37 -0700
From: Andi Kleen <ak@...ux.intel.com>
To: Baokun Li <libaokun1@...wei.com>
Cc: linux-ext4@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 01/17] ext4: add ext4_try_lock_group() to skip busy
 groups

> As Ted mentioned, Ext4 has never guaranteed deterministic allocation. We
> do attempt a predetermined goal in ext4_mb_find_by_goal(), and this part
> has no trylock logic, meaning we'll always attempt to scan the target
> group once—that's deterministic.
> 
> However, if the target attempt fails, the primary goal for subsequent
> allocation is to find suitable free space as quickly as possible, so
> there's no need to contend with other processes for non-target groups.

If you want to do it as quickly as possible then trylock is also not a good
strategy. It requires moving the cache line of the lock from EXCLUSIVE
(on the owning CPU) to SHARED and then later back to unlock, which all require
slow communication. On a large system or with contention you will still
observe considerable latencies.

Better to figure out a scheme that doesn't require touching the lock
at all.

-Andi