linux-kernel - fuse: fuse semantics wrt stalled requests

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <20241128035401.GA10431@google.com>
Date: Thu, 28 Nov 2024 12:54:01 +0900
From: Sergey Senozhatsky <senozhatsky@...omium.org>
To: Miklos Szeredi <miklos@...redi.hu>
Cc: Tomasz Figa <tfiga@...omium.org>, linux-fsdevel@...r.kernel.org,
	linux-kernel@...r.kernel.org,
	Sergey Senozhatsky <senozhatsky@...omium.org>
Subject: fuse: fuse semantics wrt stalled requests

Hello Miklos,

A question: does fuse define any semantics for stalled requests handling?

We are currently looking at a number of hung_task watchdog crashes with
tasks waiting forever in d_wait_lookup() for dentries to lose PAR_LOOKUP
state, and we suspect that those dentries are from fuse mount point
(we also sometimes see hung_tasks in fuse_lookup()->fuse_simple_request()).
Supposedly (a theory) some tasks are in request_wait_answer() under
PAR_LOOKUP, and the rest of tasks are waiting for them to finish and clear
PAR_LOOKUP bit.

request_wait_answer() waits indefinitely, however, the interesting
thing is that it uses wait_event_interruptible() (when we wait for
!fc->no_interrupt request to be processed).  What is the idea behind
interruptible wait?  Is this, may be, for stall requests handling?
Does fuse expect user-space to watchdog or monitor its processes/threads
that issue syscalls on fuse mount points and, e.g., SIGKILL stalled ones?

To make things even more complex, in our particular case fuse mount
point mounts a remote google driver, so it become a network fs in
some sense, which adds a whole new dimension of possibilities for
stalled/failed requests.  How those are expected to be handled?  Should
fuse still wait indefinitely or would it make sense to add a timeout
to request_wait_answer() and FR_INTERRUPTED timeout-ed requests?