Re: [PATCH v2 1/1] fs/writeback: skip AS_NO_DATA_INTEGRITY mappings in wait_sb_inodes()

[Joanne Koong <joannelkoong@gmail.com>]

On Wed, Jan 7, 2026 at 2:12 AM Jan Kara <jack@suse.cz> wrote:
>
> On Tue 06-01-26 15:30:05, Joanne Koong wrote:
> > On Tue, Jan 6, 2026 at 1:34 AM Jan Kara <jack@suse.cz> wrote:
> > > [Thanks to Andrew for CCing me on patch commit]
> >
> > Sorry, I didn't mean to exclude you. I hadn't realized the
> > fs-writeback.c file had maintainers/reviewers listed for it. I'll make
> > sure to cc you next time.
>
> No problem, I don't think it's formally spelled out anywhere. It's just
> that for changes in fs/*.c people tend to CC VFS maintainers / reviewers.
>
> Thanks for the historical perspective, it does put some more peace into my
> mind that things were considered :)
>
> > For the fsync() and truncate() examples you mentioned, I don't think
> > it's an issue that these now wait for the server to finish the I/O and
> > hang if the server doesn't. I think it's actually more correct
> > behavior than what we had with temp pages, eg imo these actually ought
> > to wait for the writeback to have been completed by the server. If the
> > server is malicious / buggy and fsync/truncate hangs, I think that's
> > fine given that fsync/truncate is initiated by the user on a specific
> > file descriptor (as opposed to the generic sync()) (and imo it should
> > hang if it can't actually be executed correctly because the server is
> > malfunctioning).
>
> Here, I have a comment. The hang in truncate is not as innocent as you
> might think. It will happen in truncate_inode_pages() and as such it will
> also end up hanging inode reclaim. Thus kswapd (or other arbitrary process
> entering direct reclaim) may hang in inode reclaim waiting for
> truncate_inode_pages() to finish. And at that point you are between a rock
> and a hard place - truncate_inode_pages() cannot fail because the inode is
> at the point of no return. You cannot just detach the folio under writeback
> from the mapping because if the writeback ever completes, the IO end
> handlers will get seriously confused - at least in the generic case, maybe
> specifically for FUSE there would be some solution possible - like a
> special handler in fuse_evict_inode() walking all the pages under writeback
> and tearing them down in a clean way (properly synchronizing with IO
> completion) before truncate_inode_pages() is called.

Hmm... I looked into this path a bit when I was investigating a
deadlock that was unrelated to this. The ->evict_inode() callback gets
invoked only if the ref count on an inode has dropped to zero. In
fuse, in the .release() callback (fuse_release()), if writeback
caching is enabled, write_inode_now() is called on the inode with
sync=1 (WB_SYNC_ALL). This does synchronous writeback and returns (and
drops the inode ref) only after all the dirty pages have been written
out. When ->evict_inode() -> fuse_evict_inode() is called, I don't
think there can be any lingering dirty pages to write out in
trunate_inode_pages().

Thanks,
Joanne

>
>                                                                 Honza
> --
> Jan Kara <jack@suse.com>
> SUSE Labs, CR