[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Bug 1877384] Re: 9pfs file create with mapped-xattr can fail on overlay
From: |
Christian Schoenebeck |
Subject: |
[Bug 1877384] Re: 9pfs file create with mapped-xattr can fail on overlayfs |
Date: |
Wed, 20 May 2020 12:16:16 -0000 |
Good! Then just for the case ...
Compiling the 9pfs test cases:
cd build
make tests/qtest/qos-test
Running the test cases:
export QTEST_QEMU_BINARY=x86_64-softmmu/qemu-system-x86_64
tests/qtest/qos-test
All 9pfs test cases are in:
tests/qtest/virtio-9p-test.c
The 9pfs test cases are using a simulated filesystem driver called 'synth'
driver:
hw/9pfs/9p-synth.c
That 'synth' driver is exclusively used for the 9pfs test cases, it is not used
for anything else, so you can add there whatever you need to simulate any file
system behaviour required for your test case.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1877384
Title:
9pfs file create with mapped-xattr can fail on overlayfs
Status in QEMU:
New
Bug description:
QEMU Version: 3.1.0 as packaged in debian buster, but the code appears to do
the same in master.
qemu command-line: qemu-system-x86_64 -m 1G -nographic -nic
"user,model=virtio-net-pci,tftp=$(pwd),net=10.0.2.0/24,host=10.0.2.2" -fsdev
local,id=fs,path=$thisdir/..,security_model=mapped-xattr -device
virtio-9p-pci,fsdev=fs,mount_tag=fs -drive
"file=$rootdisk,if=virtio,format=raw" -kernel "$kernel" -initrd "$initrd"
-append "$append"
I'm using CI that runs in a Docker container and runs a qemu VM with code and
results shared via virtio 9p.
The 9p fsdev is configured with security_model=mapped-xattr
When the test code attempts to create a log file in an existing directory,
open with O_CREAT fails with -ENOENT.
The relevant strace excerpt is:
28791 openat(11, ".", O_RDONLY|O_NOFOLLOW|O_PATH|O_DIRECTORY) = 20
28791 openat(20, "src", O_RDONLY|O_NOCTTY|O_NONBLOCK|O_NOFOLLOW|O_DIRECTORY)
= 21
28791 fcntl(21, F_SETFL, O_RDONLY|O_DIRECTORY) = 0
28791 close(20) = 0
28791 openat(21, "client.log",
O_WRONLY|O_CREAT|O_NOCTTY|O_NONBLOCK|O_NOFOLLOW, 0600) = 20
28791 fcntl(20, F_SETFL, O_WRONLY|O_CREAT|O_NONBLOCK|O_NOFOLLOW) = 0
28791 lsetxattr("/proc/self/fd/21/client.log", "user.virtfs.uid", "\0\0\0",
4, 0) = -1 ENOENT (No such file or directory)
My hypothesis for what's going wrong is since the Docker container's
overlayfs copies-up on writes, when it opens the file it's created a
new version of the `src` directory containing a `client.log`, but this
new src directory isn't accessible by file descriptor 20 and the
lsetxattr call is instead attempting to set attributes on the path in
the old `src` directory.
Looking at the code, a fix would be to change `hw/9pfs/9p-local.c` and
change `local_open2` to instead of calling `local_set_xattrat` to set
the xattrs by directory file descriptor and file name, to have a
version of local_set_xattrat` which uses `fsetxattr` to set the virtfs
attributes instead of the `fsetxattrat_nofollow` helper.
This reliably happened for me in CI, but I don't have access to the CI
host or the time to strip the test down to make a minimal test case,
and had difficulty reproducing the error on other machines.
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1877384/+subscriptions