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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <aUxqVn0DO7ee9K2_@codewreck.org>
Date: Thu, 25 Dec 2025 07:33:58 +0900
From: Dominique Martinet <asmadeus@...ewreck.org>
To: Pierre Barre <pierre@...re.sh>
Cc: ericvh@...nel.org, lucho@...kov.net, linux_oss@...debyte.com,
	v9fs@...ts.linux.dev, linux-kernel@...r.kernel.org,
	David Howells <dhowells@...hat.com>
Subject: Re: [BUG] 9p: data corruption with cache=mmap under concurrent
 stat/write

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?

if it doesn't work we need a better look

>   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?

-- 
Dominique Martinet | Asmadeus