Re: [BUG] fuse: wb_wait_for_completion hang on suspend with fuse-overlayfs on tmpfs persists in 6.19.6 (AS_NO_DATA_INTEGRITY fix incomplete)

[Joanne Koong <joannelkoong@gmail.com>]

On Sun, Mar 15, 2026 at 4:24 AM John <therealgraysky@proton.me> wrote:
>

Hi John,

Thanks for your detailed report.

> Kernel: 6.19.6-arch1-1
> Component: fs/fuse, fs/fs-writeback
>
> --- SUMMARY ---
>
> A suspend-to-RAM hang in wb_wait_for_completion() via sync_inodes_sb() persists on 6.19.6 when fuse-overlayfs is mounted on tmpfs. The fix introduced in 6.19~rc6 for Debian bug #1120058 ("fs/writeback: skip AS_NO_DATA_INTEGRITY mappings in wait_sb_inodes()") does not cover this code path.
>
> --- BACKGROUND ---
>
> This issue was originally reported in:
> https://github.com/containers/fuse-overlayfs/issues/386
>
> The fuse-overlayfs developer identified it as a kernel issue. It was subsequently bisected to commit 0c58a97f919c ("fuse: remove tmp folio for writebacks and internal rb tree", merged in 6.16) and tracked in Debian as bug #1120058. The fix applied in 6.19~rc6 targets wait_sb_inodes(), but the hang in the reporter's original trace and in this report occurs in sync_inodes_sb() via a separate code path that the fix does not reach.
>
> The issue is also known to syzbot as "INFO: task hung in sync_inodes_sb" with open instances on linux-5.15, linux-6.1, and linux-6.6:
>
> https://syzkaller.appspot.com/bug?extid=e0232bd63c6e293aaf6a
> https://syzkaller.appspot.com/bug?extid=4983a35cf671e5ed55b3
>
> --- REPRODUCTION ---
>
> mkdir -p /dev/shm/test/up
> mkdir -p /dev/shm/test/tmp
> mkdir -p /dev/shm/test/data
>
> fuse-overlayfs -o "static_nlink,noacl,\
>   upperdir=/dev/shm/test/up,\
>   lowerdir=$HOME/.config/mozilla/firefox,\
>   workdir=/dev/shm/test/tmp" \
>   /dev/shm/test/data
>
> firefox --profile /dev/shm/test/data/PROFILENAME
>
> Browse to youtube and start playing a video then trigger suspend while the video is playing in the browser. I used XFCE4 suspend from the menu.
>
> The display goes blank and does not recover. The system does not enter suspend. Switching to a tty shows the system is alive but X11 is frozen. Reboot is blocked:
>
> # reboot
> Call to Reboot failed: Action suspend already in progress, refusing requested reboot operation.
>
> --- CALL TRACE (6.19.6) ---
>
> Mar 15 06:44:42 kernel: INFO: task kworker/u128:0:106160 blocked for more than 122 seconds.
> Mar 15 06:44:42 kernel:       Not tainted 6.19.6-arch1-1 #1
> Mar 15 06:44:42 kernel: task:kworker/u128:0  state:D stack:0     pid:106160 tgid:106160 ppid:2
> Mar 15 06:44:42 kernel: Workqueue: pm_fs_sync pm_fs_sync_work_fn
> Mar 15 06:44:42 kernel: Call Trace:
> Mar 15 06:44:42 kernel:  <TASK>
> Mar 15 06:44:42 kernel:  __schedule+0x457/0x1720
> Mar 15 06:44:42 kernel:  schedule+0x27/0xd0
> Mar 15 06:44:42 kernel:  wb_wait_for_completion+0x97/0xe0
> Mar 15 06:44:42 kernel:  sync_inodes_sb+0xf8/0x2e0
> Mar 15 06:44:42 kernel:  __iterate_supers+0xdc/0x160
> Mar 15 06:44:42 kernel:  ksys_sync+0x43/0xb0
> Mar 15 06:44:42 kernel:  pm_fs_sync_work_fn+0x17/0xa0
> Mar 15 06:44:42 kernel:  process_one_work+0x193/0x350
> Mar 15 06:44:42 kernel:  worker_thread+0x1a1/0x310
> Mar 15 06:44:42 kernel:  kthread+0xfc/0x240
> Mar 15 06:44:42 kernel:  ret_from_fork+0x243/0x280
> Mar 15 06:44:42 kernel:  ret_from_fork_asm+0x1a/0x30
> Mar 15 06:44:42 kernel:  </TASK>
>
> --- MORE CONTEXT ---
>
> Compared to the original report (which ran through systemd-sleep -> pm_suspend -> ksys_sync), the sync call in 6.19 has been moved into a kernel workqueue via pm_fs_sync_work_fn. The hang point is identical: wb_wait_for_completion() inside sync_inodes_sb() never returns because the FUSE daemon (fuse-overlayfs) is unable to complete writeback while the suspend freezer is in progress.
>
> The AS_NO_DATA_INTEGRITY fix targets wait_sb_inodes(), which is a separate function from sync_inodes_sb(). The hung writeback completion wait in sync_inodes_sb() is not gated by the AS_NO_DATA_INTEGRITY check and remains unaddressed.

I'll need to run the repro and verify this is the issue, but I think
it's because it's hitting this call chain if there's a dirty folio
that is already under writeback that needs to have writeback issued on
it again:

wb_workfn()
  wb_do_writeback()
    wb_writeback()
      writeback_sb_inodes()
        __writeback_single_inode()
          do_writepages()
            fuse_writepages()
              iomap_writepages()
                writeback_iter()
                  writeback_get_folio()
                    folio_prepare_writeback()

where in the folio_prepare_writeback() logic:

        if (!folio_test_dirty(folio))
                return false;

        if (folio_test_writeback(folio)) {
                if (wbc->sync_mode == WB_SYNC_NONE)
                        return false;
                folio_wait_writeback(folio);


Could you verify if this fixes the issue?:

diff --git a/fs/fs-writeback.c b/fs/fs-writeback.c
index 8f8069fb76ba..4cbb22d80acf 100644
--- a/fs/fs-writeback.c
+++ b/fs/fs-writeback.c
@@ -1990,9 +1990,13 @@ static long writeback_sb_inodes(struct super_block *sb,
                 * Don't bother with new inodes or inodes being freed, first
                 * kind does not need periodic writeout yet, and for the latter
                 * kind writeout is handled by the freer.
+                *
+                * For sync(2), skip inodes whose mappings have no data
+                * integrity guarantees (eg FUSE).
                 */
                spin_lock(&inode->i_lock);
-               if (inode_state_read(inode) & (I_NEW | I_FREEING |
I_WILL_FREE)) {
+               if ((inode_state_read(inode) & (I_NEW | I_FREEING |
I_WILL_FREE)) ||
+                   (wbc.for_sync &&
mapping_no_data_integrity(inode->i_mapping))) {
                        redirty_tail_locked(inode, wb);
                        spin_unlock(&inode->i_lock);
                        continue;

I think the changes from commit f9a49aa302a0 ("fs/writeback: skip
AS_NO_DATA_INTEGRITY mappings in wait_sb_inodes()") are still needed
even with the above patch since afaics, the writeback we wait on could
have been from a previous background/periodic writeback run before
sync was triggered.

Thanks,
Joanne

>
> Note: prior to commit 0c58a97f919c, sync() on FUSE filesystems was effectively a no-op, which avoided this hang at the cost of correctness. The regression was introduced when that commit made sync() actually wait on FUSE writeback completion.
>
> I am using Arch Linux but users of Fedora F43 and Debian testing are hitting this bug also. See refs below.
>
> References:
> 1. fuse-overlayfs upstream issue: https://github.com/containers/fuse-overlayfs/issues/386
> 2. profile-sync-daemon issue: https://github.com/graysky2/profile-sync-daemon/issues/411
> 3. Debian bug #1120058: https://bugs.debian.org/1120058