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

Message-ID: <CAOQ4uxj8mncxy_LOYejGWtokh=C2WpDcGFqj+-k+imVtEk-84A@mail.gmail.com>
Date: Fri, 29 Aug 2025 11:31:30 +0200
From: Amir Goldstein <amir73il@...il.com>
To: NeilBrown <neil@...wn.name>
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 Fri, Aug 29, 2025 at 3:25 AM NeilBrown <neil@...wn.name> wrote:
>
> 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().
>

Do you mean revert c971e6a006175 kill d_instantiate_no_diralias()?

In any case, I hope that in the end the semantics of state of dentry after
lookup/create will be more clear than they are now...

Thanks,
Amir.