On Sun, 12 May 2024 at 22:31, Al Viro <viro@xxxxxxxxxxxxxxxxxx> wrote:
>
> Recall what d_delete() will do if you have other references.
> That's why we want shrink_dcache_parent() *before* d_delete().
Ahh. Yes. So with the shrinking done after as my patch, that means
that now the directory that gets removed is always unhashed.
> BTW, example of the reasons why d_delete() without directory being locked
> is painful
Oh, I would never suggest moving the d_delete() of the directory being
removed itself outside the lock.
I agree 100% on that side.
That said, maybe it's ok to just always unhash the directory when
doing the vfs_rmdir(). I certainly think it's better than unhashing
all the negative dentries like the original patch did.
Ho humm. Let me think about this some more.
We *could* strive for a hybrid approach, where we handle the common
case ("not a ton of child dentries") differently, and just get rid of
them synchronously, and handle the "millions of children" case by
unhashing the directory and dealing with shrinking the children async.
But now it's the merge window, and I have 60+ pull requests in my
inbox, so I will have to go back to work on that.
Linus
