linux-kernel - Re: [GIT PULL] bcachefs fixes for 6.15-rc4

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

Message-ID: <CAHk-=wjGiu1BA_hOBYdaYWE0yMyJvMqw66_0wGe_M9FBznm9JQ@mail.gmail.com>
Date: Fri, 25 Apr 2025 21:11:18 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Kent Overstreet <kent.overstreet@...ux.dev>
Cc: linux-bcachefs@...r.kernel.org, linux-fsdevel@...r.kernel.org, 
	linux-kernel@...r.kernel.org
Subject: Re: [GIT PULL] bcachefs fixes for 6.15-rc4

On Fri, 25 Apr 2025 at 20:59, Kent Overstreet <kent.overstreet@...ux.dev> wrote:
>
> Yeah, Al just pointed me at generic_set_sb_d_ops().
>
> Which is a perverse way to hide an ops struct. Bloody hell...

Kent, it's that perverse thing EXACTLY FOR THE REASONS I TOLD YOU.

The common case will never even *look* at the dentry ops, because
that's way too damn expensive, and the common case wants nothing at
all to do with case insensitivity.

So guess why that odd specialized function exists?

Exactly because the dcache makes damn sure that the irrelevant CI case
is never in the hot path. So when you set those special dentry
operations to say that you want the CI slow-paths, the VFS layer then
sets magic bits in the dentry itself that makes it go to there.

That way the dentry code doesn't do the extra check for "do I have
special dentry operations for hashing on bad filesystems?" IOW, in
order to avoid two pointer dereferences, we set one bit in the dentry
flags instead, and now we have that information right there.

So yes, people who want to use case-insensitive lookups need to go to
some extra effort, exactly because we do NOT want that garbage to
affect the well-behaved paths.

And no, I'm not surprised that you didn't get it all right. The VFS
layer is complicated, and the dentry cache is some of the more complex
parts of it.

And a lot of that complexity comes from all the performance tuning -
and a small part of it has very much been about getting this CI crap
out of the way.

A much bigger part has admittedly been all the locking complexity, the
RCU lookup, and the whole extra 'struct path' layer that allows us to
share the same dentry across multiple mounts.

The credit for almost all of *that* complexity goes to Al. Because
some of that code scares even me, and I'm supposed to know that part
of the kernel better than most.

             Linus