summary refs log tree commit diff stats
path: root/results/classifier/gemma3:12b/files/1336794
diff options
context:
space:
mode:
Diffstat (limited to 'results/classifier/gemma3:12b/files/1336794')
-rw-r--r--results/classifier/gemma3:12b/files/133679457
1 files changed, 57 insertions, 0 deletions
diff --git a/results/classifier/gemma3:12b/files/1336794 b/results/classifier/gemma3:12b/files/1336794
new file mode 100644
index 000000000..b94fe436f
--- /dev/null
+++ b/results/classifier/gemma3:12b/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