From: Christoph Hellwig <hch@infradead.org>
To: Joanne Koong <joannelkoong@gmail.com>
Cc: syzbot <syzbot+d3a62bea0e61f9d121da@syzkaller.appspotmail.com>,
brauner@kernel.org, djwong@kernel.org,
linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-xfs@vger.kernel.org, syzkaller-bugs@googlegroups.com
Subject: Re: [syzbot] [iomap?] WARNING in ifs_free
Date: Fri, 20 Feb 2026 09:07:27 -0800 [thread overview]
Message-ID: <aZiUz-yBUWHOhejZ@infradead.org> (raw)
In-Reply-To: <CAJnrk1bk7jN8SfHny9nVWZZS6tP8bnQbMZHTCuFma6-YuMugAg@mail.gmail.com>
On Thu, Feb 19, 2026 at 04:46:58PM -0800, Joanne Koong wrote:
> The folio is uptodate but the ifs uptodate bitmap is not reflected as
> fully uptodate. I think this is because ntfs3 handles writes for
> compressed files through its own interface that doesn't go through
> iomap where it calls folio_mark_uptodate() but the ifs bitmap doesn't
> get updated. fuse-blk servers that operate in writethrough mode run
> into something like this as well [2].
>
> This doesn't lead to any data corruption issues. Should we get rid of
> the WARN_ON_ONCE(ifs_is_fully_uptodate(folio, ifs) !=
> folio_test_uptodate(folio))? The alternative is to make a modified
> version of the functionality in "iomap_set_range_uptodate()" a public
> api callable by subsystems.
I'd honestly rather have ntfs3 come along and explain what their
doing. They've copy and pasted large chunks of the buffered
read code for now reason, which already annoys me and I'd rather
not paper over random misuses.
prev parent reply other threads:[~2026-02-20 17:07 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-15 8:12 [syzbot] [iomap?] WARNING in ifs_free syzbot
2026-02-19 20:51 ` syzbot
2026-02-20 0:46 ` Joanne Koong
2026-02-20 17:07 ` Christoph Hellwig [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aZiUz-yBUWHOhejZ@infradead.org \
--to=hch@infradead.org \
--cc=brauner@kernel.org \
--cc=djwong@kernel.org \
--cc=joannelkoong@gmail.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-xfs@vger.kernel.org \
--cc=syzbot+d3a62bea0e61f9d121da@syzkaller.appspotmail.com \
--cc=syzkaller-bugs@googlegroups.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox