linux-kernel - Re: [PATCH] fs: rework I_NEW handling to operate without fences

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: <ndpmuv4j2ycl5w5ssagzijgsykjo7mfzwenrrlvlhnbzpszlcr@3hkkdfmc54rz>
Date: Wed, 22 Oct 2025 11:41:17 +0200
From: Jan Kara <jack@...e.cz>
To: Mateusz Guzik <mjguzik@...il.com>
Cc: brauner@...nel.org, viro@...iv.linux.org.uk, jack@...e.cz, 
	linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org
Subject: Re: [PATCH] fs: rework I_NEW handling to operate without fences

On Sat 11-10-25 00:17:36, Mateusz Guzik wrote:
> In the inode hash code grab the state while ->i_lock is held. If found
> to be set, synchronize the sleep once more with the lock held.
> 
> In the real world the flag is not set most of the time.
> 
> Apart from being simpler to reason about, it comes with a minor speed up
> as now clearing the flag does not require the smp_mb() fence.
> 
> While here rename wait_on_inode() to wait_on_new_inode() to line it up
> with __wait_on_freeing_inode().
> 
> Signed-off-by: Mateusz Guzik <mjguzik@...il.com>
> ---
> 
> This temporarily duplicated sleep code from inode_wait_for_lru_isolating().
> This is going to get dedupped later.
> 
> There is high repetition of:
> 	if (unlikely(isnew)) {
> 		wait_on_new_inode(old);
> 		if (unlikely(inode_unhashed(old))) {
> 			iput(old);
> 			goto again;
> 		}
> 
> I expect this is going to go away after I post a patch to sanitize the
> current APIs for the hash.

Yeah, it seems all but one caller (ilookup5_nowait() which is only used by
AFS) would be fine with waiting for I_NEW inodes as a part of hash lookup
similarly as we wait for I_FREEING. What AFS is doing is beyond me as it
seems to be playing weird tricks with I_NEW in afs_fetch_status_success().

Anyway with the promise of deduplication I think this is moving in a good
direction so feel free to add:

Reviewed-by: Jan Kara <jack@...e.cz>

								Honza
-- 
Jan Kara <jack@...e.com>
SUSE Labs, CR