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

[Ian Kent]

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.

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