[cryptosven76]

Second change for RED-51747, complementary to #264. It is independent of #264 (same base) so each can be reviewed on its own.

Problem

Under DLM with the writeback cache, i_size is only this node's view. Writers claim their own extension under fi->lock, and the server's size is applied only when a GETATTR reply happens to arrive. A partial EOF page can hold another node's bytes, read in by the read-modify-write READ under a write grant. iomap treats them as post-EOF:

• iomap_writeback_handle_eof() zeroes them in the folio before writeback. Linux 6.17: fuse: do not send the zeroed EOF folio tail in iomap writeback #264 stops those zeros from being sent, but they stay in the clean, uptodate folio.
• iomap_block_needs_zeroing() (pos >= i_size) can zero-fill instead of reading a partial block that holds another node's data.

Change

A READ reply proves the file reaches at least pos + res: redfsd returns a short count (nob=0 for a page past its EOF) and zero-filled pages for holes inside the file. In fuse_do_readfolio(), under fc->dlm && fc->writeback_cache, raise i_size to that end:

• monotonically, under fi->lock;
• bumping attr_version like fuse_read_update_size(), so an older in-flight GETATTR reply cannot shrink it back and truncate_pagecache() the data;
• skipped while FUSE_I_SIZE_UNSTABLE marks a local truncate or size-changing setattr in progress.

With this, the read-modify-write read that pulls in another node's bytes also moves the local EOF past them, so iomap never zeroes them. #264 stays useful as a guard that writeback never sends bytes past the EOF it zeroed at.

Review points

• Remote truncate: a truncate on another node revokes every grant above its new size before it proceeds, and the next attribute reply carries the smaller size. Can a READ reply that predates the truncate still raise i_size after the revoke? The attr_version bump would then make that stale size win over a GETATTR that started before the read completed. Worth checking against the -truncate branch.
• Speculative-extension retract in fuse_cache_write_iter(): it shrinks i_size only if it still equals that writer's claimed end. A read-raised size is treated as a concurrent extender and kept, which looks right. A read-raised size equal to exactly that end would be retracted, which is harmless but imprecise.
• Readahead (fuse_readpages_end()) is not changed. The kernel does not read ahead past the local i_size, so the RMW and read_folio paths through fuse_do_readfolio() are the ones that matter.

Testing

Compile-tested only: built as DKMS 20261016.readsize1 against Ubuntu 6.17.0-42 with no warnings. It has not been run yet. The RED-51747 reproducer (red/red PR 29256) on tyan-h3-u24 can test it alone and together with #264.

🤖 Generated with Claude Code

[cryptosven76]

close in favor of #267