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: <CAP4dvsdRtO6BX6A-LdJDyakVucLskTvOViZRGonoMsK0eNtM1g@mail.gmail.com>
Date: Wed, 7 Jan 2026 10:43:12 +0800
From: Zhang Tianci <zhangtianci.1997@...edance.com>
To: Joanne Koong <joannelkoong@...il.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，

> 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.

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.

Thanks,
Tianci