linux-ext4 - Re: [PATCH 1/2] fs/dcache: introduce d_alloc_parallel_check

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: <20240822011345.GS504335@ZenIV>
Date: Thu, 22 Aug 2024 02:13:45 +0100
From: Al Viro <viro@...iv.linux.org.uk>
To: Gabriel Krisman Bertazi <krisman@...e.de>
Cc: Eugen Hristev <eugen.hristev@...labora.com>, brauner@...nel.org,
	tytso@....edu, linux-ext4@...r.kernel.org, jack@...e.cz,
	adilger.kernel@...ger.ca, linux-fsdevel@...r.kernel.org,
	linux-kernel@...r.kernel.org, kernel@...labora.com,
	shreeya.patel@...labora.com
Subject: Re: [PATCH 1/2] fs/dcache: introduce d_alloc_parallel_check_existing

On Wed, Aug 21, 2024 at 07:22:39PM -0400, Gabriel Krisman Bertazi wrote:

> Would it be acceptable to just change the dentry->d_name here in a new
> flavor of d_add_ci used only by these filesystems? We are inside the
> creation path, so the dentry has never been hashed.  Concurrent lookups
> will be stuck in d_wait_lookup() until we are done and will never become
> invalid after the change because the lookup was already done
> case-insensitively, so they all match the same dentry, per-definition,
> and we know there is no other matching dentries in the directory.  We'd
> only need to be careful not to expose partial names to concurrent
> parallel lookups.

*Ow*

->d_name stability rules are already convoluted as hell; that would make
them even more painful.

What locking are you going to use there?