linux-kernel - Re: [External] Re: [PATCH] fuse: add hang check in request_wait

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>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <7cd19bb7-2aa8-4950-b0e0-c52d59f37f7d@bsbernd.com>
Date: Thu, 8 Jan 2026 14:19:08 +0100
From: Bernd Schubert <bernd@...ernd.com>
To: Joanne Koong <joannelkoong@...il.com>,
 Zhang Tianci <zhangtianci.1997@...edance.com>
Cc: miklos@...redi.hu, linux-fsdevel@...r.kernel.org,
 linux-kernel@...r.kernel.org, xieyongji@...edance.com,
 zhujia.zj@...edance.com, Jiachen Zhang <zhangjiachen.jaycee@...edance.com>
Subject: Re: [External] Re: [PATCH] fuse: add hang check in
 request_wait_answer()

Hi Joanne,

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