9pfs does not honor open file handles on unlinked files
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
QEMU |
Expired
|
Undecided
|
Unassigned | ||
Ubuntu |
Confirmed
|
Undecided
|
Unassigned |
Bug Description
This was originally filed over here: https:/
The open-unlink-fstat idiom used in some places to create an anonymous private temporary file does not work in a QEMU guest over a virtio-9p filesystem.
Version-Release number of selected component (if applicable):
qemu-kvm-
qemu-system-
(those are fedora RPMs)
How reproducible:
Always. See this example C program:
https:/
Steps to Reproduce:
1. Export a filesystem with virt-manager for the guest.
(type: mount, driver: default, mode: passthrough)
2. Start guest and mount that filesystem
(mount -t 9p -o trans=virtio,
3. Run a program that uses open-unlink-fstat
(in my case it was trying to compile Perl 5.20)
Actual results:
fstat fails:
open("/
unlink(
fstat(3, 0x23aa1a8) = -1 ENOENT (No such file or directory)
close(3)
Expected results:
open("/
unlink(
fstat(3, {st_mode=
fcntl(3, F_SETFD, FD_CLOEXEC) = 0
close(3)
Additional info:
There was a patch put into the kernel back in '07 to handle this very problem for other filesystems; maybe its helpful:
http://
There is also a thread on LKML from last December specifically about this very problem:
https:/
There was a discussion on the QEMU list back in '11 that doesn't seem to have come to a conclusion, but did provide the test program that i've attached to this report:
Changed in qemu: | |
status: | New → Confirmed |
assignee: | nobody → Greg Kurz (gkurz) |
Changed in qemu: | |
status: | Confirmed → In Progress |
This bug makes it difficult to run a Debian Jessie guest with a 9pfs root filesystem, because "apt-get update" uses the open-unlink-fstat idiom. With this bug present, apt dies with the following error:
E: Unable to determine file size for fd 7 - fstat (2: No such file or directory)