From: Ian Kent <raven@themaw.net>
To: Krystian Kaniewski <krystianmkaniewski@gmail.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Tejun Heo <tj@kernel.org>,
"Rafael J . Wysocki" <rafael@kernel.org>,
Danilo Krummrich <dakr@kernel.org>,
Alexander Viro <viro@zeniv.linux.org.uk>,
Christian Brauner <brauner@kernel.org>, Jan Kara <jack@suse.cz>,
Ingo Molnar <mingo@redhat.com>,
Peter Zijlstra <peterz@infradead.org>,
Andrew Morton <akpm@linux-foundation.org>,
Jens Axboe <axboe@kernel.dk>,
driver-core@lists.linux.dev, autofs@vger.kernel.org,
linux-fsdevel@vger.kernel.org, linux-mm@kvack.org,
linux-kernel@vger.kernel.org,
syzbot+002fb7b2d0bc53bf7e75@syzkaller.appspotmail.com
Subject: Re: [PATCH 0/2] kernfs, autofs: fix pipe lock cycles through sysfs stores
Date: Tue, 27 Oct 2026 06:07:59 +0800 [thread overview]
Message-ID: <dc65c28e408d6b64d4b13b7ad30e5fe70ddaa441.camel@themaw.net> (raw)
In-Reply-To: <cover.1792577179.git.krystianmkaniewski@gmail.com>
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.
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
next prev parent reply other threads:[~2026-10-26 22:08 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-10 4:26 [syzbot] [autofs?] possible deadlock in anon_pipe_prefill_and_lock syzbot
2026-09-18 10:46 ` syzbot
2026-09-23 11:06 ` syzbot
2026-10-21 12:51 ` [PATCH 0/2] kernfs, autofs: fix pipe lock cycles through sysfs stores Krystian Kaniewski
2026-10-21 12:51 ` [PATCH 1/2] kernfs: do not hold of->mutex across sysfs ->store() Krystian Kaniewski
2026-10-21 12:51 ` [PATCH 2/2] autofs: do not wait for the daemon while splice holds a pipe Krystian Kaniewski
2026-10-21 21:48 ` [PATCH 0/2] kernfs, autofs: fix pipe lock cycles through sysfs stores Tejun Heo
2026-10-22 2:46 ` Ian Kent
2026-10-23 14:05 ` Krystian Kaniewski
2026-10-23 18:33 ` Tejun Heo
2026-10-26 2:03 ` Ian Kent
2026-10-26 22:07 ` Ian Kent [this message]
2026-10-26 23:11 ` Ian Kent
2026-10-27 0:46 ` Ian Kent
2026-10-27 0:57 ` Krystian Kaniewski
2026-10-27 1:06 ` Krystian Kaniewski
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=dc65c28e408d6b64d4b13b7ad30e5fe70ddaa441.camel@themaw.net \
--to=raven@themaw.net \
--cc=akpm@linux-foundation.org \
--cc=autofs@vger.kernel.org \
--cc=axboe@kernel.dk \
--cc=brauner@kernel.org \
--cc=dakr@kernel.org \
--cc=driver-core@lists.linux.dev \
--cc=gregkh@linuxfoundation.org \
--cc=jack@suse.cz \
--cc=krystianmkaniewski@gmail.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=rafael@kernel.org \
--cc=syzbot+002fb7b2d0bc53bf7e75@syzkaller.appspotmail.com \
--cc=tj@kernel.org \
--cc=viro@zeniv.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®