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

On Fri, 21 Aug 2026 at 10:30, Peter Zijlstra <[email protected]> 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.

> 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.

Thanks,
Miklos