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: <1696785.1767599663@warthog.procyon.org.uk>
Date: Mon, 05 Jan 2026 07:54:23 +0000
From: David Howells <dhowells@...hat.com>
To: Christian Schoenebeck <linux_oss@...debyte.com>
Cc: dhowells@...hat.com, Pierre Barre <pierre@...re.sh>,
    Dominique Martinet <asmadeus@...ewreck.org>, ericvh@...nel.org,
    lucho@...kov.net, v9fs@...ts.linux.dev, linux-kernel@...r.kernel.org
Subject: Re: [BUG] 9p: data corruption with cache=mmap under concurrent stat/write

Christian Schoenebeck <linux_oss@...debyte.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