Re: v9fs does not honor open file handles on anonymous files

From: Dominique Martinet
Date: Tue Dec 31 2013 - 14:47:23 EST


Richard Yao wrote on Tue, Dec 31, 2013 :
> #!/bin/bash
> cat <<-EOF
> Running this causes bash to fork via clone(), set fd=0 to point to an
> empty file in /tmp, unlink it and then execve cat. Specifically,
> something like this;
> [pid 3699] open("/tmp/sh-thd-1388524249",
> [pid 3699] open("/tmp/sh-thd-1388524249", O_RDONLY) = 4
> [pid 3699] close(3) = 0
> [pid 3699] unlink("/tmp/sh-thd-1388524249") = 0
> [pid 3699] dup2(4, 0) = 0
> [pid 3699] close(4) = 0
> [pid 3699] execve("/bin/cat", ["cat"], [/* 22 vars */]) = 0
> It seems that v9fs_vfs_unlink() is killing the file while we still have
> open file handles. I have confirmed that this behavior occurs on Linux
> 3.13.0-rc6. This breaks several things when Gentoo is on a 9p rootfs
> (e.g. gcc-config, any emerge command that involves a C compiler,
> etcetera) inside QEMU. I have placed /tmp and /var/tmp/portage on a
> tmpfs as a hack-fix, but it would be better to get this fixed.
> I doubt that I will write a patch to fix this. I am sending the details
> to the list so the 9p maintainers or any other interested individual can
> fix it.

I'm not sure if it is the client's job to remember the file has been
unlinked and only really unlink it after all the file handles are closed
or if we should expect the server to do it.

It might not matter in the case of qemu acting as a 9p server, but there
are a couple of network 9p2000.L servers out there (diod[1] and
nfs-ganesha[2]), and if the file is open on one client and unlinked on
another client.. How can the second client wait properly?

For what's it's worth, nfs-ganesha already behaves properly and this
will work with /tmp being a 9P mount off it.

It might be worth looking into qemu's code and see if it wouldn't be
easy to hold the unlink ? I've got to admit I honestly have no clue
(or at least send them a copy of your mail :))

[1] diod "Distributed I/O daemon" -
[2] nfs-ganesha -

Dominique Martinet
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at