Re: [PATCH v3 20/21] __dentry_kill(): new locking scheme

[Al Viro <viro@zeniv.linux.org.uk>]

On Mon, Jul 07, 2025 at 11:19:17PM +0100, Al Viro wrote:
> On Mon, Jul 07, 2025 at 11:47:04PM +0200, Max Kellermann wrote:
> > On Mon, Jul 7, 2025 at 11:32 PM Al Viro <viro@zeniv.linux.org.uk> wrote:
> > > The second d_walk() does not have the if (!data.found) break; after it.
> > > So if your point is that we should ignore these and bail out as soon as we
> > > reach that state, we are not getting any closer to it.
> > 
> > Not quite. My point is that you shouldn't be busy-waiting. And
> > whatever it is that leads to busy-waiting, it should be fixed
> > 
> > I don't know how the dcache works, and whatever solution I suggest,
> > it's not well-founded. I still don't even know why you added that "<0"
> > check.
> 
> Take a look at shrink_dcache_for_umount().  We really should not progress
> past it in such situation.  And dentry can be in a shrink list *WITHOUT*
> the need to pin the superblock it belongs to.

... and the same goes for memory pressure, BTW.

Suppose you have a tree with everything in it having refcounts equal to number
of their children.  _Nothing_ is busy, nothing is getting evicted at the moment.

You are asked to evict everything evictable in there.  It would be rather odd
if you ended up with some dentries sticking around (_still_ with refcounts
equal to the number of their surviving children) just because in the middle
of your work a memory pressure had been applied and started evicting one of
the leaves in that tree (none of them busy, all leaves have refcount 0, so
all of them are evictable).