linux-kernel - Re: [PATCH v6 9/9] ovl: Support mounting case-insensitive enabled layers

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: <175643072654.2234665.6159276626818244997@noble.neil.brown.name>
Date: Fri, 29 Aug 2025 11:25:26 +1000
From: "NeilBrown" <neil@...wn.name>
To: "Amir Goldstein" <amir73il@...il.com>
Cc: "Gabriel Krisman Bertazi" <gabriel@...sman.be>,
 André Almeida <andrealmeid@...lia.com>,
 "Miklos Szeredi" <miklos@...redi.hu>, "Theodore Tso" <tytso@....edu>,
 linux-unionfs@...r.kernel.org, linux-kernel@...r.kernel.org,
 linux-fsdevel@...r.kernel.org, "Alexander Viro" <viro@...iv.linux.org.uk>,
 "Christian Brauner" <brauner@...nel.org>, "Jan Kara" <jack@...e.cz>,
 kernel-dev@...lia.com
Subject:
 Re: [PATCH v6 9/9] ovl: Support mounting case-insensitive enabled layers

On Thu, 28 Aug 2025, Amir Goldstein wrote:
> 
> Neil,
> 
> FYI, if your future work for vfs assumes that fs will alway have the
> dentry hashed after create, you may want to look at:
> 
> static int ovl_instantiate(struct dentry *dentry, struct inode *inode,
> ...
>         /* Force lookup of new upper hardlink to find its lower */
>         if (hardlink)
>                 d_drop(dentry);
> 
>         return 0;
> }
> 
> If your assumption is not true for overlayfs, it may not be true for other fs
> as well. How could you verify that it is correct?

I don't need the dentry to be hashed after the create has completed (or
failed).
I only need it to be hashed when the create starts, and ideally for the
duration of the creation process.
Several filesystems d_drop() a newly created dentry so as to trigger a
lookup - overlayfs is not unique.

> 
> I really hope that you have some opt-in strategy in mind, so those new
> dirops assumptions would not have to include all possible filesystems.

Filesystems will need to opt-in to not having the parent locked.  If
a fs still has the parent locked across operations it doesn't really
matter when the d_drop() happens.  However I want to move all the
d_drop()s to the end (which is where ovl has it) to ensure there are no
structural issues that mean an early d_drop() is needed.  e.g. Some
filesystems d_drop() and then d_splice_alias() and I want to add a new
d_splice_alias() variant that doesn't require the d_drop().

So it is only at the start of an operation (create, remove, rename) that
I need the dentry to be hashed.  That raises questions about ext4_lookup
not hashing a negative dentry as a lookup-create pair in do_mknodat or
lookup_open could call vfs_create with a non-hashed dentry.
That isn't *actually* a problem (I think - I should double-check) as the
dentry is still d_in_lookup() so it is hashed in the separate
in_lookup_hashtable().  So a d_lookup() will find it even though it
isn't hashed.

That suggests an alternate fix for ovl_parent_lock().  Rather than
insisting that the child is hashed, we can insist that either
    d_in_lookup(child) || !d_unhashed(child)

Such a dentry really is hashed: it might be hashed in one table, it
might be hashed in the other.

However that wouldn't protect against filesystems which deliberately
d_drop() during create, so I think ovl still needs to perform a lookup
after a create and before a rename - if the create succeeds but the
dentry is negative.

Thanks,
NeilBrown