On Mon, Nov 27, 2023 at 12:19:09PM -0600, Eric W. Biederman wrote: > Either we should decide it is useless and remove it and all of it's > children. > > Or we should decide it was renamed and just handle it that way. How? An extra roundtrip to server trying to do getattr on the fhandle we've got? Cost of that aside, we *still* need to dissolve submounts in such case; there is no warranty that we'll ever guess the new name and no way to ask the server for one, so we can't let them sit around. Not that having mounts (local by definition) suddenly show up in the unexpected place because of rename on server looks like a good thing, especially since had that rename on server been done as cp -rl + rm -rf the same mounts would be gone... > If we can record such a decision on the dentry or possibly on the inode > then we can resolve the race by having it be a proper race of which > comes first. > > It isn't a proper delete of the inode so anything messing with the inode > and marking it S_DEAD is probably wrong. s/probably/certainly/, but where would d_invalidate() do such a thing? It's none of its business... > The code could do something like mark the dentry dont_mount which should > be enough to for d_splice_alias to say oops, something is not proper > here. Let the d_invalidate do it's thing. > > Or the code could remove the dentry from inode->i_dentry and keep > d_splice alias from finding it, and it's children completely. > That is different from unhashing it. We might be just in the middle of getdents(2) on the directory in question. It can be opened; we can't do anything that destructive there. Again, it's about the d_invalidate() on ->d_revalidate() reporting 0; uses like proc_invalidate_siblings_dcache() are separate story, simply because there d_splice_alias() is not going to move anything anywhere.
