public inbox for v9fs@lists.linux.dev
 help / color / mirror / Atom feed
From: "Pierre Barre" <pierre@barre.sh>
To: ericvh@kernel.org, lucho@ionkov.net, asmadeus@codewreck.org
Cc: linux_oss@crudebyte.com, v9fs@lists.linux.dev,
	linux-kernel@vger.kernel.org
Subject: [BUG] 9p: data corruption with cache=mmap under concurrent stat/write
Date: Wed, 24 Dec 2025 15:29:01 +0100	[thread overview]
Message-ID: <aea6cd1d-ff2b-4288-8196-edfdfd1539f6@app.fastmail.com> (raw)

Hi,

I'm hitting data corruption using 9p with cache=mmap when stat() is called concurrently with writes.

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

Thanks,
Pierre Barre

             reply	other threads:[~2025-12-24 14:29 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-12-24 14:29 Pierre Barre [this message]
2025-12-24 22:33 ` [BUG] 9p: data corruption with cache=mmap under concurrent stat/write Dominique Martinet
2025-12-25 10:23   ` Christian Schoenebeck
2025-12-25 14:52     ` Pierre Barre
2025-12-26 13:13       ` Pierre Barre
2026-01-05  7:54     ` David Howells

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=aea6cd1d-ff2b-4288-8196-edfdfd1539f6@app.fastmail.com \
    --to=pierre@barre.sh \
    --cc=asmadeus@codewreck.org \
    --cc=ericvh@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux_oss@crudebyte.com \
    --cc=lucho@ionkov.net \
    --cc=v9fs@lists.linux.dev \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox