From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ej1-f45.google.com (mail-ej1-f45.google.com [209.85.218.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 969C92B9A4 for ; Fri, 2 Jan 2026 14:37:38 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.218.45 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767364660; cv=none; b=lsptKRoT34CEnBH3u5maC5mYrWlFaIDKq+nB8dYaB/mU28KHQH3J0zh75fRURJS6G8cZwzImGu4tw16x76zrOov8Jup+Lw33LZTstiXgy3aw06GDmIQgbNvredZEh07+0EdEAICR1+EmA70lEyPublreHLUSgCF+jFfLeA/+pww= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767364660; c=relaxed/simple; bh=TELarO23MSfAM9iY6A1YcDG/q/qwxBPR9xcJ38ahsCk=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=pSCYslS5AhOQ9xm0Bkoo2RIwOLjfVrWQm+i5d4Ks18SToapBXTAcNWXoO/yX+JL8L/wct4d2M2dMshWtTpbrKwUNgd62jtjclr6vAo7lazIYtERKFkM8foZ6njILisrEcXJ1FlGGuUG+5gLsJz61ubGXBFx3Pe5YrAygRa7W0YY= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=debian.org; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=hpizdR68; arc=none smtp.client-ip=209.85.218.45 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=debian.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="hpizdR68" Received: by mail-ej1-f45.google.com with SMTP id a640c23a62f3a-b736ffc531fso2196723766b.1 for ; Fri, 02 Jan 2026 06:37:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1767364657; x=1767969457; darn=vger.kernel.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:sender :from:to:cc:subject:date:message-id:reply-to; bh=8vwnxI3Yh+PC+lgwoiNcA+XdysMGpWJnMhSYk6HzGCg=; b=hpizdR68hmczQjkGLYa3RfrBXzvBnIQvnqPPV4WG+kh5YD7CyTenk1sLmrHTIaRUyv MxWsQb1C4H2De9kMrZ7roGWlyHjdjmbHOPUTspuRNhd0jVOm8ulrJgyuvvFdrEqYljKt rBepe+ZYba0c6rpeBugfVG12xZspjvfbrr/nrn0/0yoQc82y+Sf8cHoAa3XJoITNnuC3 tjKnJVr/lMfdRq6V40mXCNmEUkWUkDQsOCQJ5v4aewwb2CcQP+oveM3n6aKLhqwZ62+X xWQSqhgsE5Ow12yU8fxWRc0Hsm6jc7u+xIK4bgXWTWkT4EjNpkHnFGs2sZp/9k6lQRab NjaA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767364657; x=1767969457; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:sender :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=8vwnxI3Yh+PC+lgwoiNcA+XdysMGpWJnMhSYk6HzGCg=; b=GHonfBRefYlLEo//Gz47kfVuRttWRRh3eL3H34KJNGKeHskakKv5YvAQqJSvR3ffqQ FOyISHr5zBD3pqG6CpIIf/rNdJ/xBjvfrXvlpPDJaYmfe7gDSNEHpPWmSLC1R85pam6i EOxeeOi4BU2EIHtEidgaCjxkhdzAuPqYhijHR03wp1JSROzL9IJFeB0q8c09AFltaxPH QoorsbLuHB0QhxGcAZkGUucxGeW5WvjoVzytsEm854zufCPOWEHf3SM+bhrD612o1A5R SxzTpFHQYdScNrGH4SqmNM6+2uOuppM75tAd4GnPAO0MjMHcQoOQtegSxB+BNFTk/rUb 8Zlg== X-Forwarded-Encrypted: i=1; AJvYcCWipIVJOHyqY6/dhaj9tyLV1gRbLgJzcgPJ7XSYghYWzv/cMQ035361VBlo0eH5axPniTbZWMQhP53uhIo=@vger.kernel.org X-Gm-Message-State: AOJu0YyBRCipUJ9ujsp9kAHV4AL0/j3/e7/ZkMoxUFrK7fHWTrT/gsuj 8sGOuHyzG4+xweYqTvGGCOi2n5+r7Rlgj9A4KZ3KGBuY1YSLUsTZO89nled73C7H X-Gm-Gg: AY/fxX6dSDlvi3KD6wF8pBzvpNGiqMevjkEfEJLW6V3SyqkVFFVyFzgra0uSNUOGNzs thSNIHpeIkX6iZj50A2slJtMSQyA0OHkWyE6KmAl2QoARj8xXa42ZBYyF9kgbMeqcgGQcRcOS2m M9j6PeoNWbrQ5ufiphsRIeS/5Uw9c9Ai9ZSpF6V10w9VSLQ3HHZz1WYvVJ1bPuL8qAAHnKoaZaM SCKp135vs+kKTXGoW/ewBrnd5UQNmM0xbAuZFfnltentIUsRtaTQlASSfDKQM10xQpOuSBUjaRO EA9eT6CTig+EZX/K4CQpC5X9VYX9keWN8JcMUfLP5buKYVJABnWAngom45ZbHN1fZncL0Uper1c wW+uRg6nzLjXQf/s4ZDESw+V2XkQGwsdUAYybUIP+pNkc4bVPRWcjJDK+hPoYwL4XUNJKGGwiQ7 9woTLZyhxXr2VJt9TDqm98N1lUYXWuTcaZ3DXd7tSbLOPj X-Google-Smtp-Source: AGHT+IH1KBuo6JG6vASIeb2V7qRjpvjk+kkYcpah7AGYC5IaaeIeL01hwyaf5hmN+BVXy1Rk+MzVCA== X-Received: by 2002:a05:600c:310c:b0:46e:32dd:1b1a with SMTP id 5b1f17b1804b1-47d1953b941mr402475615e9.7.1767358284358; Fri, 02 Jan 2026 04:51:24 -0800 (PST) Received: from eldamar.lan (c-82-192-244-13.customer.ggaweb.ch. [82.192.244.13]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-47be3a4651bsm311220285e9.7.2026.01.02.04.51.23 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 02 Jan 2026 04:51:23 -0800 (PST) Sender: Salvatore Bonaccorso Received: by eldamar.lan (Postfix, from userid 1000) id 9EBF0BE2DE0; Fri, 02 Jan 2026 13:51:22 +0100 (CET) Date: Fri, 2 Jan 2026 13:51:22 +0100 From: Salvatore Bonaccorso To: Joanne Koong Cc: =?iso-8859-1?Q?J=2E_Neusch=E4fer?= , 1120058@bugs.debian.org, Jingbo Xu , Jeff Layton , Miklos Szeredi , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, regressions@lists.linux.dev Subject: Re: [regression] 0c58a97f919c ("fuse: remove tmp folio for writebacks and internal rb tree") results in suspend-to-RAM hang on AMD Ryzen 5 5625U on test scenario involving podman containers, x2go and openjdk workload Message-ID: References: <176227232774.2636.13973205036417925311.reportbug@probook> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Hi Joanne, On Mon, Dec 15, 2025 at 06:37:42AM +0800, Joanne Koong wrote: > On Sun, Dec 14, 2025 at 10:27 PM Salvatore Bonaccorso wrote: > > > > Hi Joanne, > > > > In Debian J. Neuschäfer reported an issue where after 0c58a97f919c > > ("fuse: remove tmp folio for writebacks and internal rb tree") a > > specific, but admittely not very minimal workload, involving podman > > contains, x2goserver and a openjdk application restults in > > suspend-to-ram hang. > > > > The report is at https://bugs.debian.org/1120058 and information on > > bisection and the test setup follows: > > > > On Sun, Nov 30, 2025 at 02:11:13PM +0100, J. Neuschäfer wrote: > > > On Fri, Nov 28, 2025 at 09:10:25PM +0100, Salvatore Bonaccorso wrote: > > > > Control: found -1 6.17.8-1 > > > > > > > > Hi, > > > > > > > > On Fri, Nov 28, 2025 at 11:50:48AM +0100, J. Neuschäfer wrote: > > > > > On Wed, Nov 05, 2025 at 06:09:43AM +0100, Salvatore Bonaccorso wrote: > > > [...] > > > > > I can reproduce the bug fairly reliably on 6.16/17 by running a specific > > > > > podman container plus x2go (not entirely sure which parts of this is > > > > > necessary). > > > > > > > > Okay if you have a very reliable way to reproduce it, would you be > > > > open to make "your hands bit dirty" and do some bisecting on the > > > > issue? > > > > > > Thank you for your detailed instructions! I've already started and completed > > > the git bisect run in the meantime. I had to restart a few times due to > > > mistakes, but I was able to identify the following upstream commit as the > > > commit that introduced the issue: > > > > > > https://git.kernel.org/linus/0c58a97f919c24fe4245015f4375a39ff05665b6 > > > > > > fuse: remove tmp folio for writebacks and internal rb tree > > > > > > The relevant commit history is as follows: > > > > > > * 2619a6d413f4c3 Merge tag 'fuse-update-6.16' of git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/fuse <-- bad > > > |\ > > > | * dabb9039102879 fuse: increase readdir buffer size > > > | * 467e245d47e666 readdir: supply dir_context.count as readdir buffer size hint > > > | * c31f91c6af96a5 fuse: don't allow signals to interrupt getdents copying > > > | * f3cb8bd908c72e fuse: support large folios for writeback > > > | * 906354c87f4917 fuse: support large folios for readahead > > > | * ff7c3ee4842d87 fuse: support large folios for queued writes > > > | * c91440c89fbd9d fuse: support large folios for stores > > > | * cacc0645bcad3e fuse: support large folios for symlinks > > > | * 351a24eb48209b fuse: support large folios for folio reads > > > | * d60a6015e1a284 fuse: support large folios for writethrough writes > > > | * 63c69ad3d18a80 fuse: refactor fuse_fill_write_pages() > > > | * 3568a956932621 fuse: support large folios for retrieves > > > | * 394244b24fdd09 fuse: support copying large folios > > > | * f09222980d7751 fs: fuse: add dev id to /dev/fuse fdinfo > > > | * 18ee43c398af0b docs: filesystems: add fuse-passthrough.rst > > > | * 767c4b82715ad3 MAINTAINERS: update filter of FUSE documentation > > > | * 69efbff69f89c9 fuse: fix race between concurrent setattrs from multiple nodes > > > | * 0c58a97f919c24 fuse: remove tmp folio for writebacks and internal rb tree <-- first bad commit > > > | * 0c4f8ed498cea1 mm: skip folio reclaim in legacy memcg contexts for deadlockable mappings > > > | * 4fea593e625cd5 fuse: optimize over-io-uring request expiration check > > > | * 03a3617f92c2a7 fuse: use boolean bit-fields in struct fuse_copy_state > > > | * a5c4983bb90759 fuse: Convert 'write' to a bit-field in struct fuse_copy_state > > > | * 2396356a945bb0 fuse: add more control over cache invalidation behaviour > > > | * faa794dd2e17e7 fuse: Move prefaulting out of hot write path > > > | * 0486b1832dc386 fuse: change 'unsigned' to 'unsigned int' > > > * 0fb34422b5c223 Merge tag 'vfs-6.16-rc1.netfs' of git://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs <-- good > > > > > > The first and last commits shown are merge commits done by Linus Torvalds. The > > > fuse-update branch was based on v6.15-rc1, under which I can't run my test due > > > to an unrelated bug, so I ended up merging in 0fb34422b5c223 to test the > > > commits within the fuse-update branch. e.g.: > > > > > > git reset --hard 394244b24fdd09 && git merge 0fb34422b5c223 && make clean && make > > > > > > > > > I have also verified that the issue still happens on v6.18-rc7 but I wasn't > > > able to revert 0c58a97f919 on top of this release, because a trivial revert > > > is not possible. > > > > > > My test case consists of a few parts: > > > > > > - A podman container based on the "debian:13" image (which points to > > > docker.io/library/debian via /etc/containers/registries.conf.d/shortnames.conf), > > > where I installed x2goserver and a openjdk-21-based application; It runs the > > > OpenSSH server and port 22 is exposed as localhost:2001 > > > - x2goclient to start a desktop session in the container > > > > > > Source code: https://codeberg.org/neuschaefer/re-workspace > > > > > > I suspect, but haven't verified, that the X server in the container somehow > > > uses the FUSE-emulated filesystem in the container to create a file that is > > > used with mmap (perhaps to create shared pages as frame buffers). > > > > > > > > > Raw bisect notes: > > > > > > good: > > > - v6.12.48+deb13-amd64 > > > - v6.12.59 > > > - v6.12 > > > - v6.14 > > > - v6.15-1304-g14418ddcc2c205 > > > - v6.15-10380-gec71f661a572 > > > - v6.15-10888-gb509c16e1d7cba > > > - v6.15-rc7-357-g8e86e73626527e > > > - v6.15-10933-g4c3b7df7844340 > > > - v6.15-10954-gd00a83477e7a8f > > > - v6.15-rc7-366-g438e22801b1958 (CONFIG_X86_5LEVEL=y) > > > - v6.15-rc4-126-g07212d16adc7a0 > > > - v6.15-10958-gdf7b9b4f6bfeb1 <-- first parent, 5LEVEL doesn't exist > > > - v6.15-rc4-00127-g4d62121ce9b5 > > > - v6.15-rc7-375-g61374cc145f4a5 <-- second parent, `X86_5LEVEL=y` > > > - v6.15-rc7-375-g61374cc145f4a5 <-- second parent, `X86_5LEVEL=n` > > > - v6.15-11061-g7f9039c524a351: "first bad", actually good. merge of df7b9b4f6bfeb1 61374cc145f4a5 > > > - v6.15-11093-g0fb34422b5c223 > > > - v6.15-rc1-7-g0c4f8ed498cea1 + merge = v6.15-11101-gaec20ffad33068 > > > > > > testing: > > > - v6.18-rc7 + revert: doesn't apply > > > > > > weird (ssh doesn't work): > > > - v6.15-rc1-1-g0486b1832dc386 > > > - v6.15-rc1-10-g767c4b82715ad3 > > > - v6.15-rc1-13-g394244b24fdd09: folio stuff > > > - v6.15-rc1-22-gf3cb8bd908c72e > > > - v6.15-rc1-23-gc31f91c6af96a5 > > > - next-20251128 > > > > > > bad: > > > - v6.15-rc1-8-g0c58a97f919c24 + merge = v6.15-11102-gdfc4869c8ef1f0 first bad commit > > > - v6.15-rc1-9-g69efbff69f89c9 + merge = v6.15-11103-ga7b103c57680ce > > > - v6.15-rc1-11-g18ee43c398af0b + merge = v6.15-11105-g4ad0d4fa61974c > > > - v6.15-rc1-13-g394244b24fdd09 + merge = v6.15-11107-g37da056b3b873b > > > - v6.15-11119-g2619a6d413f4c3: merge of 0fb34422b5c223 (last good) dabb9039102879 (fuse branch) > > > - v6.15-11165-gfd1f8473503e5b: confirmed bad > > > - v6.15-11401-g69352bd52b2667 > > > - v6.15-12422-g2c7e4a2663a1ab > > > - regulator-fix-v6.16-rc2-372-g5c00eca95a9a20 > > > - v6.16.12 > > > - v6.16.12 again > > > - v6.16.12+deb14+1-amd64 > > > - v6.18-rc7 > > > > Would that ring some bells to you which make this tackable? > > Hi Salvatore, > > This looks like the same issue reported in this thread [1]. The lockup > occurs when there's a faulty fuse server on the system that doesn't > complete a write request. Prior to commit 0c58a97f919c24 ("fuse: > remove tmp folio for writebacks and internal rb tree"), syncs on fuse > filesystems were effectively no-ops. This patch upstream [2] reverts > the behavior back to that. I'll send v2 of that patch and work on > getting it merged as soon as possible. Do you know did that felt trough the cracks or is it just delayed because of vacation/holiday times? Regards, Salvatore