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

[Jan Kara <jack@suse.cz>]

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.

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