diff options
Diffstat (limited to 'results/classifier/deepseek-2-tmp/output/files/1336794')
| -rw-r--r-- | results/classifier/deepseek-2-tmp/output/files/1336794 | 57 |
1 files changed, 57 insertions, 0 deletions
diff --git a/results/classifier/deepseek-2-tmp/output/files/1336794 b/results/classifier/deepseek-2-tmp/output/files/1336794 new file mode 100644 index 000000000..b94fe436f --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/files/1336794 @@ -0,0 +1,57 @@ + +9pfs does not honor open file handles on unlinked files + +This was originally filed over here: https://bugzilla.redhat.com/show_bug.cgi?id=1114221 + +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-1.6.2-6.fc20.x86_64 +qemu-system-x86-1.6.2-6.fc20.x86_64 +(those are fedora RPMs) + +How reproducible: + +Always. See this example C program: + +https://bugzilla.redhat.com/attachment.cgi?id=913069 + +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,version=9p2000.L ...) +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("/home/tst/filename", O_RDWR|O_CREAT|O_EXCL, 0600) = 3 +unlink("/home/tst/filename") = 0 +fstat(3, 0x23aa1a8) = -1 ENOENT (No such file or directory) +close(3) + +Expected results: + +open("/home/tst/filename", O_RDWR|O_CREAT|O_EXCL, 0600) = 3 +unlink("/home/tst/filename") = 0 +fstat(3, {st_mode=S_IFREG|0600, st_size=0, ...}) = 0 +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://lwn.net/Articles/251228/ + +There is also a thread on LKML from last December specifically about this very problem: + + https://lkml.org/lkml/2013/12/31/163 + +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: + + http://marc.info/?l=qemu-devel&m=130443605720648&w=2 \ No newline at end of file |