Re: [RFC][PATCH] make sure that lock_for_kill() callers drop the locks in safe order

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

On Fri, Apr 10, 2026 at 04:30:32PM -0700, Calvin Owens wrote:

> Yes exactly, I was trying a lot of different pathological behaviors and
> that was the first pattern I found that triggered the d_walk() spin
> consistently.
> 
> Initially I made the reproducer ignore itself in /proc. But it turns out
> to be much more reliable if it *doesn't*. I realized it was opening its
> own children's files in /proc/*/fd/*, and the children were also opening
> other /proc files, which is what made me suspect the magic symlinks.
> 
> > IOW, you are opening a random mix of files, both procfs and ones some processes
> > had opened, then exiting.  That triggers invalidation of your /proc/*, with
> > a _lot_ of shite that needs to be taken out.  It might be triggering a livelock
> > or a UAF somewhere in dcache or it might be something entirely different -
> > no idea at that point.  I'll look further into that, but I wouldn't be surprised
> > if it turns out to be entirely unrelated.  Would be easier to deal with if the
> > mix had been more predictable, but we have what we have...
> 
> I'm sure I can narrow down the reproducer more, I'll try a bit.

No need...  Just have parent and child share descriptor table, then let parent
wait for child and child do
	char buf[128], buf2[128];
	int fd = 0, n;
	do {
		n = fd;
		sprintf(buf, "/proc/self/fdinfo/%d", fd);
		fd = open(buf, 0);
	} while (fd >= 0);
	for (int i = 0; i <= n; i++) {
		sprintf(buf, "/proc/self/fd/%d", i);
		readlink(buf, buf2, sizeof(buf2));
	}
and that's it.

That's a nice demonstration of how nasty conditions can be arranged for
d_invalidate(); *plenty* of busy dentries in the tree (to the tune of
several millions), with some evictables scattered here and there.
If you get enough busy stuff to wade through until you find an eviction
candidate, you'll get select_collect() return D_WALK_QUIT as soon as you
get a single evictable sucker.  Of course, then you need to restart
the whole thing - with the same pile of busy ones to get through.  Repeat
for every single evictable left in there.

No memory corruption involved, just a fuckton of rescans ;-/
It *is* recoverable - you just need to flush caches hard enough and that'll
unwedge the sucker.

IMO that's a very convincing argument for not using shrink_dcache_parent()
in d_invalidate().

That goes back to 2.1.65 - very early in dcache history.  Back then (and
until about 2014, IIRC) it had been "try to evict the subtree, unhash
if they are all gone, fail otherwise"; these days it's worse, since
d_invalidate() is not allowed to fail.

"Rescan if we have found something and ran out of timeslice" is there since
2005 mingo's 116194f29f13 "[PATCH] sched: vfs: fix scheduling latencies in
prune_dcache() and select_parent()" - latency problems prior to that got
traded for this "rescan the same pile of busy stuff for each evictable"
pathological behaviour.

FWIW, it doesn't have to be on procfs - you can arrange for something similar
with fuse.

Joy...