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-=wiZ=ZBZyKfg-pyA3wmEq+RkscKB1s68c7k=3GaT48e9Jg@mail.gmail.com>
Date: Fri, 25 Apr 2025 20:40:48 -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:09, Kent Overstreet <kent.overstreet@...ux.dev> wrote:
>
> The subject is CI lookups, and I'll eat my shoe if you wrote that.

Start chomping. That nasty code with d_compare and d_hash goes way back.

>From a quick look, it's from '97, and got merged in in 2.1.50. It was
added (obviously) for FAT. Back then, that was the only case that
wanted it.

I don't have any archives from that time, and I'm sure others were
involved, but that whole init_name_hash / partial_name_hash /
end_name_hash pattern in 2.1.50 looks like code I remember. So I was
at least part of it.

The design, if you haven't figured it out yet, is that filesystems
that have case-independent name comparisons can do their own hash
functions and their own name comparison functions, exactly so that one
dentry can match multiple different strings (and different strings can
hash to the same bucket).

If you get dentry aliases, you may be doing something wrong.

Also, originally this was all in the same core dcache lookup path. So
the whole "we have to check if the filesystem has its own hash
function" ended up slowing down the normal case. It's obviously been
massively modified since 1997 ("No, really?"), and now the code is
very much set up so that the straight-line normal case is all the
non-CI cases, and then case idnependence ends up out-of-line with its
own dcache hash lookup loops so that it doesn't affect the normal good
case.

            Linus