Re: [Qemu-devel] [Bug 1336794] Re: 9pfs does not honor open file handles on unlinked files

[Eric Van Hensbergen]

I've done some digging from the client side.  As is mentioned in Miklos' original patch (which appears to have been shot down) the higher level implementation appear to be broken for this.  Here's what the code looks like for fstat in fs/stat.c:

int vfs_fstat(unsigned int fd, struct kstat *stat)

{

        struct fd f = fdget_raw(fd);

        int error = -EBADF;

        if (f.file) {

                error = vfs_getattr(&f.file->f_path, stat);

                fdput(f);

        }

        return error;

}

In other words, it only uses the open fd to derrive a path and then executes the getattr off of that path.  If that path no longer exists (because of unlink or remove) then you are hosed.  In my understanding, the "work around" I suppose is the so-called 'silly renaming' where remove/unlink simply does a rename until all open instances are closed.  

The frustrating thing is that the 9p protocol is setup to work off of the fid, which maps to the fd -- so its perfectly capable of the original semantic but the high level code in fs/stat.c only wants to give a path.  

I can do a work around on the client where a getattr "favors" open fids for the operation or I can do the sillyrename hack that NFS and CIFS has used but both of those look god-awful.

     -eric

On Fri, Apr 10, 2015 at 7:30 AM, Mark Glines <address@hidden> wrote:

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)

--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1336794

Title:
  9pfs does not honor open file handles on unlinked files

Status in QEMU:
  New

Bug description:
  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

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1336794/+subscriptions