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

[Ian Kent]

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.

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