I wonder if we could clear PG_uptodate on the page which had its zero
bytes exposed by the i_size increase?

I've actually tried that first. The idea was to get or create a new page on the EOF boundary, lock it and poison it with an uptodate reset if we need to. But this resulted in an instantaneous EIO in my test. If I undestand correctly, this is because of another race condition:

* A fresh page gets created and read by FUSE; uptodate is true;
* The page is unlocked on return from `fuse_read_folio`;
* Simultaneously, we run `getattr`. The page gets locked, uptodate is reset, the page is unlocked;
* Now back from `fuse_read_folio`, `filemap_read_folio` gets this page, waits on `folio_wait_locked_killable` (waiting for the getattr to reset uptodate), and then checks `folio_test_uptodate`;
* The page is !uptodate, so an EIO is returned.

So it effectively results in inability to have a successful `read` when a `getattr` for a growing file happens simultaneously.

Finally, if I understand correctly, this also leaves a (much smaller) theoretical race condition in `filemap_read` between checking uptodate and getting the current inode size.

Attached is the patch with this attempt; please check that it does what you meant in case I misunderstood.

Cheers,
Nikolay.