Re: [RFC PATCH 1/1] iomap: fix race between iomap_set_range_uptodate and folio_end_read

[Sasha Levin]

On Wed, Dec 24, 2025 at 05:27:03PM +0000, Matthew Wilcox wrote:
> On Wed, Dec 24, 2025 at 10:43:58AM -0500, Sasha Levin wrote:
> > On Wed, Dec 24, 2025 at 02:10:19AM +0000, Matthew Wilcox wrote:
> > > So Sasha has produced a very convincingly worded writeup that's
> > > hallucinated.
> >
> > And spent a few hours trying to figure it out so I could unblock testing, but
> > sure - thanks.
>
> When you produce a convincingly worded writeup that's utterly wrong,
> and have a reputation for using AI, that's the kind of reaction you're
> going to get.

A rude and unprofessional one?

> > Here's the full log:
> > https://qa-reports.linaro.org/lkft/sashal-linus-next/build/v6.18-rc7-13806-gb927546677c8/testrun/30618654/suite/log-parser-test/test/exception-warning-fsiomapbuffered-io-at-ifs_free/log
> > , happy to test any patches you might have.
>
> That's actually much more helpful because it removes your incorrect
> assumptions about what's going on.
>
> WARNING: fs/iomap/buffered-io.c:254 at ifs_free+0x130/0x148, CPU#0: msync04/406
>
> That's this one:
>
>        WARN_ON_ONCE(ifs_is_fully_uptodate(folio, ifs) !=
>                        folio_test_uptodate(folio));
>
> which would be fully explained by fuse calling folio_clear_uptodate()
> in fuse_send_write_pages().  I have come to believe that allowing
> filesystems to call folio_clear_uptodate() is just dangerous.  It
> causes assertions to fire all over the place (eg if the page is mapped
> into memory, the MM contains assertions that it must be uptodate).
>
> So I think the first step is simply to delete the folio_clear_uptodate()
> calls in fuse:

[snip]

Here's the log of a run with the change you've provided applied: https://qa-reports.linaro.org/lkft/sashal-linus-next/build/v6.18-rc7-13807-g26a15474eb13/testrun/30620754/suite/log-parser-test/test/exception-warning-fsiomapbuffered-io-at-ifs_free/log

--
Thanks,
Sasha