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

[Peter Zijlstra <peterz@infradead.org>]

On Fri, Aug 21, 2026 at 04:33:57PM +0200, Miklos Szeredi wrote:
> On Fri, 21 Aug 2026 at 10:30, Peter Zijlstra <peterz@infradead.org> wrote:
> 
> > That would be adding conditionals to the mutex, something we all pay
> > for, always.
> 
> It's just one bit (could be stashed  into LSB of ->first_waiter),
> Condition is checked before going to sleep, i.e. adds one branch in
> the slow path.  Don't think this could be measurable.

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.

> > One way would be for each file op to be wrapped like 'link-$op-unlink'
> > such that the client (the task doing the file op) gets linked to the
> > server (the task responsible for satisfying the request) before it can
> > block, and unlinked once its done.
> 
> Okay, how do you know which task or tasks are responsible for
> satisfying the request?  That's not a generally calculable
> information.
> 
> sshfs is a simple example: the transport layer process is ssh, but it
> is in no way involved in fuse transactions, there's just a pipe
> between the two.   How would the kernel know it has to link the ssh
> process when the pipe is written to?
> 
> There are probably many such examples where this fails.

Well, it was 'your' (as in not me) suggestion to have a freeze priority,
which sorta implied you knew what tasks to apply it to :/

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.