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 03:15:16PM -0700, Calvin Owens wrote:
> On Friday 04/10 at 22:24 +0100, Al Viro wrote:
> > On Fri, Apr 10, 2026 at 02:13:10PM -0700, Calvin Owens wrote:
> > > On Friday 04/10 at 15:32 -0400, Jeff Layton wrote:
> > > > Yep, not even with that. One thing that claude pointed out: doing an
> > > > mdelay() might prevent it from making any progress freeing dentries.
> > > > I'm experimenting now with one that only randomly does a delay, but so
> > > > far that hasn't turned up anything. I'll let you know if that changes.
> > > 
> > > Hi Jeff,
> > > 
> > > I've been poking at this one too. With the attached reproducer, the
> > > waiter will get stuck in an infinite loop apparently in d_walk() with a
> > > stock 7.0-rc7 (in my case with PREEMPT_LAZY):
> > 
> > Interesting...  I'll try it in a bit, but just in case - could you check if
> > git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git #work.dcache-busy-wait
> > steps into the same thing on your setup?
> 
> Hi Al,
> 
> It still reproduces on that branch in the exact same way.
> 
> I'm absolutely 100% guessing... but I recall tomfoolery with the "magic"
> symlinks in /proc/$/fd/* in the past... the below patch makes the infinite
> spins impossible to trigger with my reproducer, does my explanation make
> any sense to you? Apologies if I'm off in the weeds...

What it's doing, AFAICS, is a weird way of opening arseloads of files, mostly
the same ones again and again - the reason it needs that prlimit (there's
way fewer files in procfs when it starts) is that these threads keep running
through each other's /proc/*/fd and opening what they'd got again and again,
adding to /proc/*/fd/* as they go.

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...