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: <CAJnrk1Zt=zS7UYbryE0S+-1qBqYaowgCGa5Eq=gK7ynnk+ybTA@mail.gmail.com>
Date: Wed, 7 Jan 2026 16:00:58 -0800
From: Joanne Koong <joannelkoong@...il.com>
To: 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()

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.

Thanks,
Joanne

>
> Thanks,
> Tianci