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

[Jan Kara <jack@suse.cz>]

On Wed 07-01-26 15:20:48, Joanne Koong wrote:
> 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().

Right, that addresses my concern. Inode reclaim on FUSE shouldn't be able
to see dirty / writeback pages. Thanks for explanation!

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