On Fri, Aug 29, 2025 at 3:25 AM NeilBrown <neil@xxxxxxxxxx> 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.
