On 8/21/24 15:47, Miklos Szeredi wrote: > On Wed, 14 Aug 2024 at 01:23, Joanne Koong <joannelkoong@xxxxxxxxx> wrote: >> >> There are situations where fuse servers can become unresponsive or take >> too long to reply to a request. Currently there is no upper bound on >> how long a request may take, which may be frustrating to users who get >> stuck waiting for a request to complete. >> >> This patchset adds a timeout option for requests and two dynamically >> configurable fuse sysctls "default_request_timeout" and "max_request_timeout" >> for controlling/enforcing timeout behavior system-wide. >> >> Existing fuse servers will not be affected unless they explicitly opt into the >> timeout. > > I sort of understand the motivation, but do not clearly see why this > is required. > > A well written server will be able to do request timeouts properly, > without the kernel having to cut off requests mid flight without the > knowledge of the server. The latter could even be dangerous because > locking guarantees previously provided by the kernel do not apply > anymore. > > Can you please explain why this needs to be done by the client > (kernel) instead of the server (userspace)? I don't know about Joannes motivation, I see two use cases - You suggested yourself that timeouts might be a (non-ideal) solution to avoid page copies on writeback https://lore.kernel.org/linux-mm/CAJfpegt_mEYOeeTo2bWS3iJfC38t5bf29mzrxK68dhMptrgamg@xxxxxxxxxxxxxx/raw - Would probably be a solution for this LXCFS issue https://lore.kernel.org/lkml/a8d0c5da-6935-4d28-9380-68b84b8e6e72@xxxxxxxxxx/ (although I don't fully understand the issue there yet) Thanks, Bernd
