linux-kernel - Re: [PATCH] 9p/virtio: restrict page pinning to user_backed

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <8622834.T7Z3S40VBb@weasel>
Date: Thu, 18 Dec 2025 16:14:45 +0100
From: Christian Schoenebeck <linux_oss@...debyte.com>
To: asmadeus@...ewreck.org
Cc: Eric Van Hensbergen <ericvh@...nel.org>,
 Latchesar Ionkov <lucho@...kov.net>, Chris Arges <carges@...udflare.com>,
 v9fs@...ts.linux.dev, linux-kernel@...r.kernel.org,
 David Howells <dhowells@...hat.com>, Matthew Wilcox <willy@...radead.org>,
 linux-fsdevel@...r.kernel.org
Subject:
 Re: [PATCH] 9p/virtio: restrict page pinning to user_backed_iter() iovec

On Thursday, 18 December 2025 15:21:43 CET asmadeus@...ewreck.org wrote:
> asmadeus@...ewreck.org wrote on Thu, Dec 18, 2025 at 06:49:04AM +0900:
> > Christian Schoenebeck wrote on Wed, Dec 17, 2025 at 02:41:31PM +0100:
> >> Something's seriously messed up with 9p cache right now. With today's git
> >> master I do get data corruption in any 9p cache mode, including
> >> cache=mmap,
> >> only cache=none behaves clean.
> > 
> > Ugh...
> 
> I've updated from v6.18-rc2 + 9p pull requests to master and I can't
> reproduce any obvious corruption, booting an alpine rootfs over 9p and
> building a kernel inside (tried cache=loose and mmap)
> 
> Won't be the first time I can't reproduce, but what kind of workload are
> you testing?
> Anything that might help me try to reproduce (like VM cpu count/memory)
> will be appreciated, corruptions are Bad...

Debian Trixie guest running as 9p rootfs in QEMU, 4 cores, 16 GB.

Compiling a bunch of projects with GCC works fine without errors, but with 
clang it's very simple for me to reproduce. E.g. just a very short C++ file 
that pulls in some system headers:

#include <utility>
#include <sys/cdefs.h>
#include <limits>

Then running 3 times: clang++ -c foo.cpp -std=c++17

The first 2 clang runs succeed, the 3rd clang run then always blows up for 
anything else than cache=none, various spurious clang errors on those system 
headers like

  error: source file is not valid UTF-8
  ...
  warning: null character ignored [-Wnull-character]
  ...
  error: expected unqualified-id

and finally clang crashes.

/Christian