Re: [PATCH v4 0/2] fuse: add timeout option for requests

[Miklos Szeredi <miklos@szeredi.hu>]

On Wed, 21 Aug 2024 at 23:22, Joanne Koong <joannelkoong@gmail.com> wrote:

> Without a kernel enforced timeout, the only way out of this is to
> abort the connection. A userspace timeout wouldn't help in this case
> with getting the server unstuck. With the kernel timeout, this forces
> the kernel handling of the write request to proceed, whihc will drop
> the folio lock and resume the server back to a functioning state.
>
> I don't think situations like this are uncommon. For example, it's not
> obvious or clear to developers that fuse_lowlevel_notify_inval_inode()
> shouldn't be called inside of a write handler in their server code.

Documentation is definitely lacking.  In fact a simple rule is: never
call a notification function from within a request handling function.
Notifications are async events that should happen independently of
handling regular operations.  Anything else is an abuse of the
interface.

>
> For your concern about potential unintended side effects of timed out
> requests without the server's knowledge, could you elaborate more on
> the VFS locking example? In my mind, a request that times out is the
> same thing as a request that behaves normally and completes with an
> error code, but perhaps not?

- user calls mknod(2) on fuse directory
- VFS takes inode lock on parent directory
- calls into fuse to create the file
- fuse sends request to server
- file creation is slow and times out in the kernel
- fuse returns -ETIMEDOUT
- VFS releases inode lock
- meanwhile the server is still working on creating the file and has
no idea that something went wrong
- user calls the same mknod(2) again
- same things happen as last time
- server starts to create the file *again* knowing that the VFS takes
care of concurrency
- server crashes due to corruption


> I think also, having some way for system admins to enforce request
> timeouts across the board might be useful as well - for example, if a
> malignant fuse server doesn't reply to any requests, the requests hog
> memory until the server is killed.

As I said, I'm not against enforcing a response time for fuse servers,
as long as a timeout results in a complete abort and not just an error
on the timed out request.

Thanks,
Miklos