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: <CAP4dvseWhaeu08NR-q=F5pRyMN5BnmWXHZi4i1L+utdjJTECaQ@mail.gmail.com>
Date: Sat, 3 Jan 2026 23:22:36 -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, I apologize for the delayed response. Happy New Year!

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

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

Thanks,
Tianci