On Sun, 12 May 2024 at 09:16, Al Viro <viro@xxxxxxxxxxxxxxxxxx> wrote:
>
> Eviction in general - sure
> shrink_dcache_parent() in particular... not really - you'd need to keep
> dentry pinned for that and that'd cause all kinds of fun for umount
> d_delete() - even worse (you don't want dcache lookups to find that
> sucker after rmdir(2) returned success to userland).
All of those dentries *should* be negative dentries, so I really don't
see the worry.
For example, any child dentries will obviously still elevate the
dentry count on the parent, so I really think we could actually skip
the dentry shrink *entirely* and it wouldn't really have any semantic
effect.
IOW, I really think the "shrink dentries on rmdir" is a "let's get rid
of pointless children that will never be used" than a semantic issue -
cleaning things up and releasing memory, rather than about behavior.
We will have already marked the inode dead, and called d_delete() on
the directory:
dentry->d_inode->i_flags |= S_DEAD;
dont_mount(dentry);
detach_mounts(dentry);
...
if (!error)
d_delete_notify(dir, dentry); // does d_delete(dentry)
so the removed directory entry itself will have either turned into a
negatve dentry or will unhash it (if there are other users).
So the children are already unreachable through that name, and can
only be reached through somebody who still has the directory open. And
I do not see how "rmdir()" can *possibly* have any valid semantic
effect on any user that has that directory as its PWD, so I claim that
the dentries that exist at this point must already not be relevant
from a semantic standpoint.
So Al, this is my argument: the only dentry that *matters* is the
dentry of the removed directory itself, and that's the one that sees
the "d_delete()" (and all the noise to make sure you can't do new
lookups and can't mount on top of it).
The dentries *underneath* it cannot matter for semantics, and can
happily be pruned - or not pruned - at any later date.
Can you address *THIS* issue?
Linus
