On Wed, 21 Aug 2024 at 20:11, Josef Bacik <josef@xxxxxxxxxxxxxx> wrote: > "A well written server" is the key part here ;). In our case we had a "well > written server" that ended up having a deadlock and we had to run around with a > drgn script to find those hung mounts and kill them manually. The usecase here > is specifically for bugs in the FUSE server to allow us to cleanup automatically > with EIO's rather than a drgn script to figure out if the mount is hung. So you 'd like to automatically abort the connection to an unresponsive server? I'm okay with that. What I'm worried about is the unintended side effects of timed out request without the server's knowledge (i.e. VFS locks released, then new request takes VFS lock). If the connection to the server is aborted, then that's not an issue. It's also much simpler to just time out any response from the server (either read or write on /dev/fuse) than having to do per-request timeouts. > It also gives us the opportunity to do the things that Bernd points out, > specifically remove the double buffering downside as we can trust that > eventually writeback will either succeed or timeout. Thanks, Well see this explanation for how this might deadlock on a memory allocation by the server: https://lore.kernel.org/all/CAJfpegsfF77SV96wvaxn9VnRkNt5FKCnA4mJ0ieFsZtwFeRuYw@xxxxxxxxxxxxxx/ Having a timeout would fix the deadlock, but it doesn't seem to me a proper solution. Thanks, Miklos
