Re: [External] Re: [PATCH] fuse: add hang check in request_wait_answer()

[Joanne Koong]

On Tue, Jan 6, 2026 at 6:43 PM Zhang Tianci
<zhangtianci.1997@xxxxxxxxxxxxx> wrote:
>
> Hi Joanne，
>
> > imo it's possible to check whether the kernel itself is affected just
> > purely through libfuse changes to fuse_lowlevel.c where the request
> > communication with the kernel happens. The number of requests ready by
> > the kernel is exposed to userspace through sysfs, so if the daemon is
> > deadlocked or cannot read fuse requests, that scenario is detectable
> > by userspace.

Hi Tianci,

>
> Yes, checking in libfuse/fuse_lowlevel.c is feasible, but it depends on
> the running state of FUSEDaemon(if FUSEDaemon is in a process exit state,
> this check cannot be performed), I think we do need this approach,
> but it cannot fully cover all scenarios. Therefore, I believe it
> should coexist with this patch.
>
> The content of the /sys/fs/fuse/connections/${devid}/waiting interface
> is inaccurate;
> it cannot distinguish between normal waiting and requests that have been hanging
> for a period of time.

I think if the fusedaemon is in a process exit state (by "process exit
state", I think you're talking about the state where
fuse_session_exit() has been called but the daemon is stuck/hanging
before actual process exit?), this can still be detected in libfuse.
For example one idea could be libfuse spinning up a watchdog monitor
thread that has logic checking if the session's mt_exited has been set
with no progress on /sys/fs/fuse/.../waiting requests being fulfilled.

Thanks,
Joanne

>
> Thanks,
> Tianci