[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#1109446: marked as done (unblock: fuse3/3.17.2-3)



Your message dated Sun, 20 Jul 2025 16:14:56 +0200
with message-id <CAM8zJQvG8cfo1v0DTv06B8W+Zit-3DKrthXyrpfFzwECW+isfw@mail.gmail.com>
and subject line Re: Bug#1109446: unblock: fuse3/3.17.2-3
has caused the Debian Bug report #1109446,
regarding unblock: fuse3/3.17.2-3
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
1109446: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1109446
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message ---
Package: release.debian.org
Severity: normal
Tags: d-i
User: release.debian.org@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: kibi@debian.org
Control: affects -1 + src:fuse3

Hi RMs,

[ Reason ]
It was reported to Ubuntu that under certain conditions fusermount3
uses 100% CPU [1]. This most probably affects Trixie as well.

[ Impact ]
Upstream fixed it, and turned out previously was using an incorrect
define to test if the close_range syscall is available or not during
compilation. This is a minimal change.
I also applied a one line change to one of the examples to fix a deadlock in it.

[ Tests ]
I tested installation, I couldn't reproduce the 100% CPU usage even before.

[ Risks ]
There's no risk, the changes correct usage to be normal. Original bug
reporter confirms the fix is working fine.
But as fuse3 has an udeb, I put kibi in the loop.

[ Checklist ]
  [x] all changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in testing

Regards,
Laszlo/GCS
[1] https://bugs.launchpad.net/fuse/+bug/2115475/
diff -Nru fuse3-3.17.2/debian/changelog fuse3-3.17.2/debian/changelog
--- fuse3-3.17.2/debian/changelog	2025-05-19 18:39:08.000000000 +0000
+++ fuse3-3.17.2/debian/changelog	2025-07-16 17:27:21.000000000 +0000
@@ -1,3 +1,11 @@
+fuse3 (3.17.2-3) unstable; urgency=medium
+
+  * Backport upstream fixes:
+    - fix the close_range ifdef,
+    - fix deadlock in truncate operation in memfs_ll.cc example. 
+
+ -- Laszlo Boszormenyi (GCS) <gcs@debian.org>  Wed, 16 Jul 2025 17:27:21 +0000
+
 fuse3 (3.17.2-2) unstable; urgency=medium
 
   [ Laszlo Boszormenyi (GCS) ]
diff -Nru fuse3-3.17.2/debian/patches/Fix-the-close_range-ifdef.patch fuse3-3.17.2/debian/patches/Fix-the-close_range-ifdef.patch
--- fuse3-3.17.2/debian/patches/Fix-the-close_range-ifdef.patch	1970-01-01 00:00:00.000000000 +0000
+++ fuse3-3.17.2/debian/patches/Fix-the-close_range-ifdef.patch	2025-07-16 17:27:21.000000000 +0000
@@ -0,0 +1,38 @@
+From 194023c5999651386a3ddbf91fdd710d661d083b Mon Sep 17 00:00:00 2001
+From: Bernd Schubert <bernd@bsbernd.com>
+Date: Tue, 15 Jul 2025 23:54:27 +0200
+Subject: [PATCH] fusermount: Fix the close_range ifdef
+
+This fixes commit 82bcd818
+That commit had removed HAVE_LINUX_CLOSE_RANGE in meson generation,
+but didn't remove the usage in fusermount.c - fusermount was then
+not using the close_range syscall.
+
+Closes: https://github.com/libfuse/libfuse/issues/1284
+Signed-off-by: Bernd Schubert <bernd@bsbernd.com>
+---
+ util/fusermount.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/util/fusermount.c b/util/fusermount.c
+index 48f7fe7fa..1b94e8e5e 100644
+--- a/util/fusermount.c
++++ b/util/fusermount.c
+@@ -36,7 +36,7 @@
+ #include <stdbool.h>
+ #include <sys/vfs.h>
+ 
+-#ifdef HAVE_LINUX_CLOSE_RANGE_H
++#ifdef HAVE_CLOSE_RANGE
+ #include <linux/close_range.h>
+ #endif
+ 
+@@ -1477,7 +1477,7 @@ static int close_inherited_fds(int cfd)
+ 	if (cfd <= STDERR_FILENO)
+ 		return -EINVAL;
+ 
+-#ifdef HAVE_LINUX_CLOSE_RANGE_H
++#ifdef HAVE_CLOSE_RANGE
+ 	if (cfd < STDERR_FILENO + 2) {
+ 		close_range_loop(STDERR_FILENO + 1, cfd - 1, cfd);
+ 	} else {
diff -Nru fuse3-3.17.2/debian/patches/memfs_ll-fix-deadlock.patch fuse3-3.17.2/debian/patches/memfs_ll-fix-deadlock.patch
--- fuse3-3.17.2/debian/patches/memfs_ll-fix-deadlock.patch	1970-01-01 00:00:00.000000000 +0000
+++ fuse3-3.17.2/debian/patches/memfs_ll-fix-deadlock.patch	2025-07-16 17:27:21.000000000 +0000
@@ -0,0 +1,27 @@
+From b96c738b10e9a308725c62b9392ba7d553eec254 Mon Sep 17 00:00:00 2001
+From: Long Li <leo.lilong@huawei.com>
+Date: Wed, 16 Jul 2025 09:54:07 +0800
+Subject: [PATCH] memfs_ll: fix deadlock in truncate operation
+
+Remove redundant mutex lock acquisition in the truncate() method to
+prevent deadlock. The issue occurs when memfs_setattr() already holds
+the mutex lock and then calls truncate(), which attempts to acquire
+the same lock again.
+
+Signed-off-by: Long Li <leo.lilong@huawei.com>
+---
+ example/memfs_ll.cc | 1 -
+ 1 file changed, 1 deletion(-)
+
+diff --git a/example/memfs_ll.cc b/example/memfs_ll.cc
+index 0da7c2544..17d7d034b 100644
+--- a/example/memfs_ll.cc
++++ b/example/memfs_ll.cc
+@@ -197,7 +197,6 @@ class Inode {
+ 
+ 	void truncate(off_t size)
+ 	{
+-		std::lock_guard<std::mutex> lock(mutex);
+ 		std::lock_guard<std::mutex> attr_lock(attr_mutex);
+ 		if (size < content.size()) {
+ 			content.resize(size);
diff -Nru fuse3-3.17.2/debian/patches/series fuse3-3.17.2/debian/patches/series
--- fuse3-3.17.2/debian/patches/series	2025-05-19 18:39:08.000000000 +0000
+++ fuse3-3.17.2/debian/patches/series	2025-07-16 17:27:21.000000000 +0000
@@ -3,3 +3,5 @@
 Make_conn-want-want_ext_conversion_non_fatal.patch
 Add-container_of-and-ROUND_UP-macros.patch
 Fix-fuse_apply_conn_info_opts.patch
+Fix-the-close_range-ifdef.patch
+memfs_ll-fix-deadlock.patch

--- End Message ---
--- Begin Message ---
unblocked

--- End Message ---

Reply to: