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

[Ian Kent <raven@themaw.net>]

On Wed, 2026-10-21 at 11:48 -1000, Tejun Heo wrote:
> Hello, Krystian.
> 
> On Wed, Oct 21, 2026 at 02:51:48PM +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.
> 
> This is an extremely convoluted case that isn't going to happen in
> any
> realistic scenario, and it doesn't make sense to change the locking
> scheme
> for it. Can we just disallow splice on /sys/power/resume instead?

I agree but it might not be as simple as disallowing that path.

Not only is the description hard to follow the example is flawed
because there should not be a mount callback on anything that's
not an empty directory or an autofs trigger mount (and the above
should be able to be either (systemd's /proc/sys/fs/binfmt_misc
is an example of an autofs trigger mount).

I mostly can't grok the reproducers for things like this so a
complicated description makes it so much harder to come up with
a sensible solution.

The other possibility I was thinking about when I saw that report
is to disallow file systems that don't make sense for automount.

That would take some thought though and isn't entirely clear for
kernfs since it's used by other file systems that may occasionally
need to automount something at some point.

OTOH, if the problem description could be cleaned up, and
simplified, I wouldn't be entirely against the change but still
wouldn't much like it. That's purely because I've always been in
favor of defensing programming even for cases that are unlikely.

Ian