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)

[John <therealgraysky@proton.me>]

On Monday, March 16th, 2026 at 8:16 PM, Joanne Koong wrote:

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

Yes, it does! Amazing!

I applied it to 6.19.8, upon rebooting and following the steps I outlined above I was able suspend and wake up three consecutive times.

Is this something you plan to submit/backport to the stable kernels series?