Swamped with other work at the moment, but this hasn't been forgotten. I might be able to take a look at it next week.
On Sat, 16 May 2020 at 12:55, Christian Schoenebeck <1877...@bugs.launchpad.net> wrote: > > Yes, that compile error with QEMU + recent kernel headers is a bit > annoying, and AFAICS it is not fixed in Debian yet. > > Would you mind writing a test case for this bug that you fixed, to > prevent this accidentally being broken in future again? > > Please note that 9pfs is currently only been taken care of by 2 people, > and both only on a side channel. The 9pfs code base is complex and error > prone to edge cases like this one, so active assistance would be very > much appreciated! > > If you might consider writing a test case, I would give you quick, easy > and short instructions how to compile the 9pfs test cases, and which > source files to touch. There is no guest OS installation required for > the test cases. > > Thanks! > > -- > You received this bug notification because you are subscribed to the bug > report. > 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 -- 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
