On Mon, Feb 24, 2025 at 12:34:06PM +1100, NeilBrown wrote: > On Sat, 22 Feb 2025, Al Viro wrote: > > On Fri, Feb 21, 2025 at 10:36:30AM +1100, NeilBrown wrote: > > > > > +In general, filesystems which use d_instantiate_new() to install the new > > > +inode can safely return NULL. Filesystems which may not have an I_NEW inode > > > +should use d_drop();d_splice_alias() and return the result of the latter. > > > > IMO that's a bad pattern, _especially_ if you want to go for "in-update" > > kind of stuff later. > > Agreed. I have a draft patch to change d_splice_alias() and > d_exact_alias() to work on hashed dentrys. I thought it should go after > these mkdir patches rather than before. Could you give a braindump on the things d_exact_alias() is needed for? It's a recurring headache when doing ->d_name/->d_parent audits; see e.g. https://lore.kernel.org/all/20241213080023.GI3387508@ZenIV/ for related mini-rant from the latest iteration. Proof of correctness is bloody awful; it feels like the primitive itself is wrong, but I'd never been able to write anything concise regarding the things we really want there ;-/
