Bug 1114221 - 9pfs does not honor open file handles on unlinked files
Summary: 9pfs does not honor open file handles on unlinked files
Keywords:
Status: CLOSED DEFERRED
Alias: None
Product: Fedora
Classification: Fedora
Component: qemu
Version: 20
Hardware: All
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Fedora Virtualization Maintainers
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-06-28 20:00 UTC by Sean Estabrooks
Modified: 2014-07-02 13:53 UTC (History)
10 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-07-02 13:53:47 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
C program that works on any filesystem except 9pfs (774 bytes, text/plain)
2014-06-28 20:00 UTC, Sean Estabrooks
no flags Details

Description Sean Estabrooks 2014-06-28 20:00:16 UTC
Created attachment 913069 [details]
C program that works on any filesystem except 9pfs

Description of problem:

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

How reproducible:

Always.

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

Comment 1 Richard W.M. Jones 2014-06-28 20:19:13 UTC
Thanks for filing this detailed bug report.

However it's not hugely surprising, and another reason either not to
use 9pfs or to get someone to maintain it properly.

This tracker only deals with bugs in Fedora's packaging of qemu, or
(sometimes) with bugs in parts of qemu written by Fedora / Red Hat
contributors.  I suggest you'll get more traction by raising this problem
on the upstream qemu-devel mailing list or the qemu bug tracker.

Comment 2 Sean Estabrooks 2014-06-28 20:36:08 UTC
Thanks Richard.  I wasn't aware that 9pfs was unmaintained and not recommended.  I'll figure something else out.  Feel free to close this bug if its a problem better handled upstream.  At least there is a record here for the next person who stumbles into this backwater.

Cheers.

Comment 3 Cole Robinson 2014-07-02 13:53:47 UTC
Thanks for the detailed report Sean. I moved this bug to the upstream tracker, please subscribe to that bug if you want to follow any progress:

https://bugs.launchpad.net/qemu/+bug/1336794


Note You need to log in before you can comment on or make changes to this bug.