Re: [PATCH v2] fuse: permit freezing while waiting for request answer

On Fri, 21 Aug 2026 at 16:57, Peter Zijlstra <[email protected]> wrote:
>
> On Fri, Aug 21, 2026 at 04:33:57PM +0200, Miklos Szeredi wrote:

> I suppose I'm not at all sure how it would differ from having
> mutex_lock_freezable(), or how it would help in this situation.

This patch allows freezing with VFS locks held.  That allows freezing
in some cases, but still fails in the contended case.  To fix the
contended case we need to allow VFS locks to be freezable also.    We
could just replace inode_lock() implementation with a freezable
variant, and that would work for fuse.  For other filesystems, it
would could break the freezer due to various locking contexts.

My idea was to make VFS level locks (i_rwsem, s_vfs_rename_mutex)
optionally freezable.  By optionally I mean normally not freezable,
but certain filesystems (fuse, nfs, cifs) could make them freezable on
initialization.

Adding mutex_lock_freezable() and moving this logic into the vfs would
mean that both fastpath and slowpath get the branch, which probably
doesn't matter in practice, but doing it only in the slowpath is
nicer.

> Anyway, I suppose that in this case the fuse server is responsible to
> communicate this dependency to the kernel -- or the sshfs fuse server
> should use libssh and embed the ssh client inside itself, instead of
> using pipes, dunno.

Quoting you upthread:
"Also, you'd be putting suspend success in the hands of userspace, that
sounds like a mighty fail right there."

Thanks,
Miklos