From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:37614) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YhIah-0005fC-FM for qemu-devel@nongnu.org; Sun, 12 Apr 2015 10:10:28 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YhIac-0000jK-Ev for qemu-devel@nongnu.org; Sun, 12 Apr 2015 10:10:27 -0400 Received: from zeniv.linux.org.uk ([195.92.253.2]:52041) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YhIac-0000RG-8t for qemu-devel@nongnu.org; Sun, 12 Apr 2015 10:10:22 -0400 Date: Sun, 12 Apr 2015 15:09:57 +0100 From: Al Viro Message-ID: <20150412140956.GN889@ZenIV.linux.org.uk> References: <20140702135258.23882.15100.malonedeb@soybean.canonical.com> <20150410123059.26540.1036.malone@gac.canonical.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: Al Viro Subject: Re: [Qemu-devel] [Bug 1336794] Re: 9pfs does not honor open file handles on unlinked files List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Bug 1336794 <1336794@bugs.launchpad.net> Cc: qemu-devel@nongnu.org On Sun, Apr 12, 2015 at 12:42:35PM -0000, Eric Van Hensbergen wrote: > 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. What do you mean, "no longer exists"? Don't confuse path with pathname - it's a mount,dentry pair. And dentry in question bloody well ought to still have the FID associated with it - you shouldn't use the same FID for TREMOVE and for TREAD/TWRITE. TREMOVE clunks the FID passed to it; on some servers you really have no choice - server discards the file completely and on any FID that used to refer to it you get an error from that point on. On those you'd really have to do something like sillyrename - the only way to keep IO going for a file sitting on such server is to have it visible somewhere. Normal fs(4) is that way; e.g. u9fs(4) isn't - there FID maps to opened file descriptor on host and TREMOVE on another FID doesn't break it, as long as host supports IO on opened-but-unlinked files. I don't remember where qemu 9pfs falls in that respect, but I'd expect it to be more like u9fs... Which FID are you passing to server on unlink()?