From: Christian Schoenebeck <1877384@bugs.launchpad.net>
To: qemu-devel@nongnu.org
Subject: [Bug 1877384] Re: 9pfs file create with mapped-xattr can fail on overlayfs
Date: Thu, 10 Dec 2020 13:49:23 -0000 [thread overview]
Message-ID: <160760816365.16006.11449144423149063527.malone@chaenomeles.canonical.com> (raw)
In-Reply-To: 158886102295.5250.16201751310283363946.malonedeb@chaenomeles.canonical.com
Good to know. Then it makes sense to close this report for now. Feel
free to reopen it if necessary.
Thanks!
** Changed in: qemu
Status: Confirmed => Incomplete
--
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:
Incomplete
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
next prev parent reply other threads:[~2020-12-10 14:21 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-07 14:17 [Bug 1877384] [NEW] 9pfs file create with mapped-xattr can fail on overlayfs Fishface60
2020-05-09 13:57 ` [Bug 1877384] " Christian Schoenebeck
2020-05-11 17:55 ` Fishface60
2020-05-16 11:49 ` Christian Schoenebeck
2020-05-18 13:15 ` Fishface60
2020-05-20 12:16 ` Christian Schoenebeck
2020-12-10 8:55 ` Thomas Huth
2020-12-10 11:46 ` Thomas Huth
2020-12-10 13:04 ` Fishface60
2020-12-10 13:49 ` Christian Schoenebeck [this message]
2021-02-09 4:17 ` Launchpad Bug Tracker
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=160760816365.16006.11449144423149063527.malone@chaenomeles.canonical.com \
--to=1877384@bugs.launchpad.net \
--cc=qemu-devel@nongnu.org \
/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;
as well as URLs for NNTP newsgroup(s).