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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Tue, 21 Nov 2023 02:27:34 +0000 From: Al Viro <viro@...iv.linux.org.uk> To: Linus Torvalds <torvalds@...ux-foundation.org> Cc: Christian Brauner <brauner@...nel.org>, Gabriel Krisman Bertazi <krisman@...e.de>, tytso@....edu, linux-f2fs-devel@...ts.sourceforge.net, ebiggers@...nel.org, linux-fsdevel@...r.kernel.org, jaegeuk@...nel.org, linux-ext4@...r.kernel.org Subject: Re: [f2fs-dev] [PATCH v6 0/9] Support negative dentries on case-insensitive ext4 and f2fs On Mon, Nov 20, 2023 at 10:07:51AM -0800, Linus Torvalds wrote: > Well, we all know - very much including Al - that Al isn't always the > most responsive person, and tends to have his own ratholes that he > dives deep into. FWIW, the right now I'm getting out of one of those - rename() deadlocks fun. Will post that, assuming it survives local beating, then post the dcache stuff and other branches (all rebased by now). Other ratholes - d_name/d_parent audit is about halfway through - we do have fun shite in quite a few ->d_revalidate() instances (UAF, etc.); RCU pathwalk methods need to be re-audited; the fixes caught in the last cycle are either in mainline by now, or rebased. But that stuff is relatively easy to suspend for a few days. > Of course, "do it in shared generic code" doesn't tend to really fix > the braindamage, but at least it's now shared braindamage and not > spread out all over. I'm looking at things like > generic_ci_d_compare(), and it hurts to see the mindless "let's do > lookups and compares one utf8 character at a time". What a disgrace. > Somebody either *really* didn't care, or was a Unicode person who > didn't understand the point of UTF-8. > > Oh well. I guess people went "this is going to suck anyway, so let's > make sure it *really* sucks". > > The patches look fine to me. Al - do you even care about them? I will review that series; my impression from the previous iterations had been fairly unpleasant, TBH, but I hadn't rechecked since April or so. Re dcache conflicts - see #untested-pile-dcache; most the dcache-affecting stuff should be there. One intersting exception is the general helper for safely picking parent/parent's inode/entry name for ->d_revalidate() use; we have the parent-related part boilerplated, but the name side tends to be missing. That's still being tweaked, looking for sane calling conventions.
Powered by blists - more mailing lists