From: David Howells <dhowells@redhat.com>
To: Christian Schoenebeck <linux_oss@crudebyte.com>
Cc: dhowells@redhat.com, Pierre Barre <pierre@barre.sh>,
Dominique Martinet <asmadeus@codewreck.org>,
ericvh@kernel.org, lucho@ionkov.net, v9fs@lists.linux.dev,
linux-kernel@vger.kernel.org
Subject: Re: [BUG] 9p: data corruption with cache=mmap under concurrent stat/write
Date: Mon, 05 Jan 2026 07:54:23 +0000 [thread overview]
Message-ID: <1696785.1767599663@warthog.procyon.org.uk> (raw)
In-Reply-To: <5951517.DvuYhMxLoT@weasel>
Christian Schoenebeck <linux_oss@crudebyte.com> wrote:
> > > 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.
getattr() may flush outstanding dirty data on an inode so that the stats are
correct - but if so, it should wait for completion. If you look at cifs and
nfs, those uses filemap_datawait() or filemap_write_and_wait(), rather then
filemap_datawrite().
You might also want to check flags & AT_STATX_FORCE_SYNC and flags &
AT_STATX_DONT_SYNC.
I really ought to make afs honour AT_STATX_FORCE_SYNC.
David
prev parent reply other threads:[~2026-01-05 7:54 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-12-24 14:29 [BUG] 9p: data corruption with cache=mmap under concurrent stat/write Pierre Barre
2025-12-24 22:33 ` 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 [this message]
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=1696785.1767599663@warthog.procyon.org.uk \
--to=dhowells@redhat.com \
--cc=asmadeus@codewreck.org \
--cc=ericvh@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux_oss@crudebyte.com \
--cc=lucho@ionkov.net \
--cc=pierre@barre.sh \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.