linux-kernel - Perf regression in 6.16-rc1 in generic/676 (readdir related)

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-next>] [day] [month] [year] [list]

Message-ID: <CAH2r5mu5SfBrdc2CFHwzft8=n9koPMk+Jzwpy-oUMx-wCRCesQ@mail.gmail.com>
Date: Mon, 9 Jun 2025 12:06:23 -0500
From: Steve French <smfrench@...il.com>
To: Christian Brauner <brauner@...nel.org>, linux-fsdevel <linux-fsdevel@...r.kernel.org>, 
	NeilBrown <neil@...wn.name>
Cc: LKML <linux-kernel@...r.kernel.org>, CIFS <linux-cifs@...r.kernel.org>, 
	Bharath S M <bharathsm@...rosoft.com>
Subject: Perf regression in 6.16-rc1 in generic/676 (readdir related)

Instead of the usual 10 to 12 minutes to run generic/676 (on all
kernels up to 6.15), we are now seeing 23-30 minutes to run
generic/676, much more than twice as slow.   It looks like this is due
to unnecessary revalidates now being sent to the fs (starting with
6.16-rc1 kernels) on every file in a directory, and is caused by
readdir.   Bharath was trying to isolate the commit that caused this,
but this recently merged series could be related:

06c567403ae5 Use try_lookup_noperm() instead of d_hash_and_lookup()
outside of VFS
fa6fe07d1536 VFS: rename lookup_one_len family to lookup_noperm and
remove permission check

Has anyone else noticed this perf regression?

For the case of cifs.ko mounts, it is easy to repro with generic/676.
And also could be reproduced with simple "ls" of large directories.

-- 
Thanks,

Steve