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: <CAJnrk1a2-HS6cqthfcU5hxBi7Rinwh8MpYggNtOg6P256aW0zw@mail.gmail.com>
Date: Mon, 5 Jan 2026 14:30:41 -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 Sat, Jan 3, 2026 at 11:22 PM Zhang Tianci
<zhangtianci.1997@...edance.com> wrote:
>
> Hi Joanne, I apologize for the delayed response. Happy New Year!
Hi Tianci,

No worries at all, happy 2026!
>
> > That makes sense. In that case, I think it's cleaner to detect and
>
> > print the corresponding debug statements for this through libfuse
>
> > instead of the kernel.
>
> Yes, you're absolutely right. From the perspective of FUSEDaemon maintainers,
> it is appropriate to place such checks in libfuse.
>
> However, from the viewpoint of personnel responsible for maintaining
> cluster kernel stability, they are more concerned with whether the
> kernel itself is affected.
>
> Additionally, if FUSEDaemon enters a state where it neither responds to kernel
> FUSE requests nor can exit during the process exit phase due to certain bugs
> (such as when FUSEDaemon incorrectly depends on the mount point it
> provides and thus enters a deadlock state), the alerts in libfuse will
> become ineffective.

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.

Thanks,
Joanne

>
> Therefore, I think there is no need for an either-or choice between kernel
> alerts and FUSEDaemon alerts.
>
> Thanks,
> Tianci