Re: [PATCH v1] fuse: Don't use request timeouts on virtiofs

[sashiko-bot@kernel.org]

> virtiofs cannot abort a request once it has been added to a virtqueue,
> because the device owns its buffers until it returns them on the used
> ring. This is why virtiofs sets no_control and no_force_umount; see
> commit 15c8e72e88e0 ("fuse: allow skipping control interface and
> forced unmount"), which says that "virtio-fs does not support aborting
> requests which are being processed".
> 
> The request timeout added by commit 0f6439f61a6e ("fuse: add
> kernel-enforced timeout option for requests") aborts them anyway. When
> a request takes longer than the timeout, fuse_check_timeout() calls
> fuse_chan_abort(), which moves the requests on each virtqueue's
> fpq->processing list to its end list and ends them, so they are freed.
> The device can then still write the reply into the freed request and
> its pages, and virtio_fs_requests_done_work() later gets the freed
> request back from virtqueue_get_buf().
> 
> The timeout is armed when the server sets FUSE_REQUEST_TIMEOUT in its
> INIT reply, or when the fs.fuse.default_request_timeout or
> fs.fuse.max_request_timeout sysctl is set, for example for other FUSE
> mounts on the same system. A slow host is then enough to hit it.
> 
> Don't arm the request timeout, and don't offer FUSE_REQUEST_TIMEOUT, on
> connections that set no_force_umount.
> 
> Fixes: 0f6439f61a6e ("fuse: add kernel-enforced timeout option for requests")
> Cc: stable@vger.kernel.org
> Signed-off-by: Yuho Choi <oss.patchbox@gmail.com>

Sashiko has reviewed this patch and found no issues.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261112052208.1248312-2-oss.patchbox@gmail.com?part=1