From: Michael Mulqueen <mike@method-b.uk>
To: David Howells <dhowells@redhat.com>
Cc: ericvh@kernel.org, lucho@ionkov.net, asmadeus@codewreck.org,
pc@manguebit.org, linux_oss@crudebyte.com, v9fs@lists.linux.dev,
netfs@lists.linux.dev, linux-fsdevel@vger.kernel.org,
regressions@lists.linux.dev
Subject: Re: PROBLEM: [REGRESSION 7.1-rc4 -> 7.1-rc5] 9p: silent NUL corruption of file data on cache modes with CACHE_WRITEBACK
Date: Fri, 11 Sep 2026 13:53:46 +0100 [thread overview]
Message-ID: <3faab0c3-29be-44af-9569-1e12e8ed6a74@method-b.uk> (raw)
In-Reply-To: <2226525.1789118704@warthog.procyon.org.uk>
Thanks all for your replies.
On 11/09/2026 08:16, David Howells wrote:
> Are you actually using this with a cache? Or just enabling the "use a
> cache" options?
This is my mistake, I hadn't set up cachefiles in my test VM. So yes,
I'm seeing what you've seen with the reproducer. Apologies for that
misdirection!
For posterity all the previously tested versions that were CORRUPT, except
v7.3-rc2 which I come to below, do this:
none read 0/20 write 0/20 [cache=0x0]
readahead read 0/20 write 0/20 [cache=0x1]
mmap read 20/20 write 20/20 [cache=0x5]
loose read 20/20 write 20/20 [cache=0xf]
fscache/unbound read 20/20 write 20/20 [cache=0x8f]
fscache/bound read 0/20 write 20/20 [cache=0x8f]
Where fscache/unbound is not having cachefiles properly configured and
fscache/bound is where it's actually active. It's the same reproducer
as before, just run twice for the fscache case - the difference is
cachefiles configuration outside the script.
On the 7.3 release candidates, I get a different result:
none read 0/20 write 0/20 [cache=0x0]
readahead read 0/20 write 0/20 [cache=0x1]
mmap read 20/20 write 20/20 [cache=0x5]
loose read 20/20 write 20/20 [cache=0xf]
fscache/unbound read 20/20 write 20/20 [cache=0x8f]
fscache/bound read 20/20 write 20/20 [cache=0x8f]
It appears that cachefiles isn't actually storing anything on 7.3. I've
used the same configuration for every version, cachefiles is active, but
seems to encounter an error when actually storing in 7.3. I haven't had
time to investigate that. I only mention this for completeness, it's
not material to fixing this bug, just affects how it presents.
On 11/09/2026 10:25, David Howells wrote:
> Does the attached work for you?
Yes, thanks, I get this on patched 7.2 and on patched 7.3-rc2:
none read 0/20 write 0/20 [cache=0x0]
readahead read 0/20 write 0/20 [cache=0x1]
mmap read 0/20 write 0/20 [cache=0x5]
loose read 0/20 write 0/20 [cache=0xf]
fscache/unbound read 0/20 write 0/20 [cache=0x8f]
fscache/bound read 0/20 write 0/20 [cache=0x8f]
So it looks like it's fixed. I haven't had a chance to try the patch
on a real workflow, only the reproducer, but I will next week and report
back.
Cheers,
Mike
next prev parent reply other threads:[~2026-09-11 12:53 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-10 10:56 PROBLEM: [REGRESSION 7.1-rc4 -> 7.1-rc5] 9p: silent NUL corruption of file data on cache modes with CACHE_WRITEBACK Michael Mulqueen
2026-09-10 12:23 ` Dominique Martinet
2026-09-10 14:06 ` Christian Schoenebeck
2026-09-11 7:16 ` David Howells
2026-09-11 8:10 ` David Howells
2026-09-11 9:25 ` David Howells
2026-09-11 12:53 ` Michael Mulqueen [this message]
2026-09-11 13:13 ` 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=3faab0c3-29be-44af-9569-1e12e8ed6a74@method-b.uk \
--to=mike@method-b.uk \
--cc=asmadeus@codewreck.org \
--cc=dhowells@redhat.com \
--cc=ericvh@kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux_oss@crudebyte.com \
--cc=lucho@ionkov.net \
--cc=netfs@lists.linux.dev \
--cc=pc@manguebit.org \
--cc=regressions@lists.linux.dev \
--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