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

[Bernd Schubert <bernd@bsbernd.com>]

Hi Joanne,

On 1/8/26 01:00, Joanne Koong wrote:
> On Tue, Jan 6, 2026 at 6:43 PM Zhang Tianci
> <zhangtianci.1997@bytedance.com> 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.

I added one kernel connection watchdog last week

https://github.com/libfuse/libfuse/commit/6278995cca991978abd25ebb2c20ebd3fc9e8a13

Thanks,
Bernd