Re: [PATCH 0/2] kernfs, autofs: fix pipe lock cycles through sysfs stores

[Ian Kent]

On Tue, 2026-10-27 at 08:46 +0800, Ian Kent wrote:
> On Tue, 2026-10-27 at 07:11 +0800, Ian Kent wrote:
> > On Tue, 2026-10-27 at 06:07 +0800, Ian Kent wrote:
> > > On Wed, 2026-10-21 at 14:51 +0200, Krystian Kaniewski wrote:
> > > > syzbot reports a lockdep cycle &pipe->mutex --> &of->mutex -->
> > > > &sbi->pipe_mutex. splice holds a pipe mutex while it calls the
> > > > write
> > > > or
> > > > read handler of a kernfs file, kernfs takes of->mutex there,
> > > > and
> > > > a
> > > > write
> > > > to /sys/power/resume looks up a path that can make autofs write
> > > > a
> > > > request
> > > > into its daemon pipe and wait for the daemon.
> > > > 
> > > > Patch 1 stops holding of->mutex around the ->store() callback
> > > > of
> > > > regular
> > > > sysfs attributes, which do not get the open file and already
> > > > run
> > > > concurrently for separate opens.
> > > > 
> > > > Patch 2 handles the case that patch 1 leaves. A store called
> > > > from
> > > > splice
> > > > still runs with the pipe locked. autofs no longer sends or
> > > > waits
> > > > for
> > > > a
> > > > request in that context and returns -EAGAIN instead. A new
> > > > mount
> > > > is
> > > > refused before it is marked pending, so no other lookup sends
> > > > the
> > > > request
> > > > in its place. This also removes a deadlock in which the spliced
> > > > pipe
> > > > is
> > > > the autofs daemon pipe itself.
> > > > 
> > > > Patch 2 changes behavior for one narrow case. A lookup from a
> > > > splice
> > > > callback that needs an automount fails with -EAGAIN instead of
> > > > waiting.
> > > > 
> > > > The series was tested in QEMU with lockdep using the original C
> > > > and
> > > > syz
> > > > reproducers and focused splice and autofs cases. The target
> > > > reports
> > > > were
> > > > not reproduced with the series applied, and the paired
> > > > functional
> > > > cases
> > > > matched the unpatched baseline.
> > > I can't seem to find a reproducer that reproduces the bug or
> > > maybe
> > > I don't know what to expect from running the syzbot reproducer I
> > > did locate.
> > 
> > I think I have found the appropriate reproducer, certainly looks
> > like it.
> > 
> > Commit 1e8c813b083c ("PM: hibernate: don't use early_lookup_bdev
> > in resume_store") looks like it's been around for a while so I
> > assume the reproducer should work on 7.2.12?
> > 
> > What should I expect, a hang, it doesn't.
> > 
> > Also it looks to me like the reproducer is trying exploit an
> > invalid request similar to what I described earlier but I can't
> > test to see if my simple autofs resolution fixes it if I don't
> > know what to expect from the reproducer.
> 
> Further investigation shows that the reproducer is initiating path
> walks within the autofs mount it has mounted which is valid in the
> sense the autofs file system will attempt to send a request over
> it's pipe. These are not seen as invalid so I can't prevent them
> in the way I thought I might be able to.
> 
> I can't confirm there is a deadlock, how do I do this?
> 
> A little more validation and I'll be in a position to review and
> probably ack the autofs changes.

Sorry for taking so long getting back but I'm struggling with a
few time critical tasks (including this one).

I haven't looked as far as I wanted to yet but I have looked at
the autofs patch again mainly because it occurred to me that the
EAGAIN return might be a bit of a problem.

The expiration of automounts has always handled EAGAIN returns
even though that handling has changed over the years. So this
amounts to little more than deferring an expire which is fine.

But mount requests have never handled EAGAIN and I'm pretty
sure this return will result in an unexpected mount fail being
returned to the requester in user space. OTOH this deadlock
case should not occur very often and neither should the case
where an automount has expired (so the mount has gone away and
hence a path walk initiated) but the automount daemon has not
yet finalised the expire by notifying the kernel.

Also I still think the scenario where this occurs is something
that will not happen in normal use and would most likely only
only occur for nefarious purposes. For these reasons it's a
little bit of an open question whether the autofs changes are OK.

Updating user space is of course possible but significantly
difficult due to the number of distributions that would/may
need to update the daemon.

Another option is to handle these EAGAIN returns for NFY_MOUNT
requests in the autofs fs itself by re-queuing the mount
request. In fact I already had a patch series to do something
very similar to handle stale request entries after a "kill -9"
followed immediately by an autofs startup. Sadly I got side
tracked by overthinking what was happening and reworked the
patch series considerably and had not tested it at all. I'm
pretty sure that a recent contributed autofs patch will fix
what lead me to this diversion and it will take a while to
recover the original series (or re-write it).

Ian
> 
> Ian
> > 
> > Ian
> > > 
> > > Can anyone help please.
> > > 
> > > Ian
> > > > 
> > > > Krystian Kaniewski (2):
> > > >   kernfs: do not hold of->mutex across sysfs ->store()
> > > >   autofs: do not wait for the daemon while splice holds a pipe
> > > > 
> > > >  fs/autofs/expire.c     |  6 +++++
> > > >  fs/autofs/root.c       | 28 +++++++++++++++++++++--
> > > >  fs/kernfs/file.c       | 52 +++++++++++++++++++++++++++-------
> > > > --
> > > > --
> > > > --
> > > > --
> > > >  fs/splice.c            | 13 ++++++++++-
> > > >  fs/sysfs/file.c        | 18 ++++++++++++++-
> > > >  include/linux/kernfs.h | 11 +++++++++
> > > >  include/linux/sched.h  |  2 ++
> > > >  kernel/fork.c          |  1 +
> > > >  8 files changed, 109 insertions(+), 22 deletions(-)
> > > > 
> > > > 
> > > > base-commit: 93f51579e7df248780214094418f205253383cc5