linux-kernel - Re: 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-prev] [day] [month] [year] [list]

Message-id: <174951588031.608730.13342747411339092972@noble.neil.brown.name>
Date: Tue, 10 Jun 2025 10:38:00 +1000
From: "NeilBrown" <neil@...wn.name>
To: "Steve French" <smfrench@...il.com>
Cc: "Christian Brauner" <brauner@...nel.org>,
 "linux-fsdevel" <linux-fsdevel@...r.kernel.org>,
 "LKML" <linux-kernel@...r.kernel.org>, "CIFS" <linux-cifs@...r.kernel.org>,
 "Bharath S M" <bharathsm@...rosoft.com>
Subject: Re: Perf regression in 6.16-rc1 in generic/676 (readdir related)

On Tue, 10 Jun 2025, Steve French wrote:
> 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

Thanks for the report.  The cause is almost certainly the first of
these.  No callers of try_lookup_noperm() need or want the revalidate.
Before my patch the only user was autofs which doesn't even have a
d_revalidate().

I'll write and post a patch.

Thanks,
NeilBrown


> 
> 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
>