Re: [BUG] 9p: data corruption with cache=mmap under concurrent stat/write

[Christian Schoenebeck <linux_oss@crudebyte.com>]

On Wednesday, 24 December 2025 23:33:58 CET Dominique Martinet wrote:
> Hi Pierre,
> 
> Pierre Barre wrote on Wed, Dec 24, 2025 at 03:29:01PM +0100:
> > I'm hitting data corruption using 9p with cache=mmap when stat() is called
> > concurrently with writes.
> Thanks for the report
> 
> > Environment:
> > - Kernel: v6.18.1-061801
> > - Mount options: cache=mmap
> > - Transport: unix
> > 
> > Reproducer:
> > 1. Mount 9p filesystem with cache=mmap
> > 2. Run PostgreSQL with data directory on 9p mount
> > 3. Run pgbench workload
> > 4. Simultaneously run `watch -n 0.1 tree -ah` on the data directory
> > 
> > PostgreSQL reports:
> >   ERROR: unexpected data beyond EOF in block N of relation "..."
> 
> unexpected data beyond EOF looks a lot like
> https://lkml.kernel.org/r/938162.1766233900@warthog.procyon.org.uk
> 
> could you try with this patch?

Pierre, I am also confident that this patch will fix the EOF data issue you 
encountered with PostgreSQL. However ...

> >   HINT: This has been seen to occur with buggy kernels
> > 
> > Analysis:
> > 
> > The issue appears to be race conditions in getattr/setattr when using
> > writeback caching:
> > 
> > 1. v9fs_vfs_getattr_dotl() condition checks `v9ses->cache` instead of
> > 
> >    `v9ses->cache & CACHE_WRITEBACK`, triggering writeback flush for
> >    any cache mode
> > 
> > 2. Both getattr and setattr call filemap_fdatawrite() which initiates
> > 
> >    writeback but doesn't wait for completion. The subsequent server
> >    stat/wstat sees stale file size.
> > 
> > Would using filemap_write_and_wait() instead be the correct fix?

... you are seeing a 2nd issue? getattr() output should not be related to 
mmap() access.

/Christian