From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:42415) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QGvLf-0004TJ-JI for qemu-devel@nongnu.org; Mon, 02 May 2011 11:47:48 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QGvLd-00071N-UV for qemu-devel@nongnu.org; Mon, 02 May 2011 11:47:47 -0400 Received: from e39.co.us.ibm.com ([32.97.110.160]:54358) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QGvLd-00070t-NE for qemu-devel@nongnu.org; Mon, 02 May 2011 11:47:45 -0400 Received: from d03relay03.boulder.ibm.com (d03relay03.boulder.ibm.com [9.17.195.228]) by e39.co.us.ibm.com (8.14.4/8.13.1) with ESMTP id p42FY0Rk030788 for ; Mon, 2 May 2011 09:34:00 -0600 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by d03relay03.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p42FlZoB044620 for ; Mon, 2 May 2011 09:47:35 -0600 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p42FksUA017685 for ; Mon, 2 May 2011 09:46:59 -0600 Message-ID: <4DBED206.6020809@linux.vnet.ibm.com> Date: Mon, 02 May 2011 08:47:18 -0700 From: Venkateswararao Jujjuri MIME-Version: 1.0 References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------010900050006040804010909" Subject: Re: [Qemu-devel] Bug in virtio-9p when fstatting an fd referring to a file that no longer exists List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org, v9fs-developer@lists.sourceforge.net, Eric Van Hensbergen This is a multi-part message in MIME format. --------------010900050006040804010909 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 04/28/2011 09:51 AM, Sassan Panahinejad wrote: > This thread seems relevant: > http://www.mail-archive.com/linux-fsdevel@vger.kernel.org/msg09159.html > Unless things have changed, it looks like the problem is in the client > kernel (although note that there isn't support in qemu, even if the > client did send an fid associated with an open file!). > Any thoughts on a workaround for this? Hrm, I don't see any workaround for this. May be we should add TFSTAT for dotl? or add a flag to TSTAT? Copying the v9fs. Thanks, JV > > > Thanks > Sassan > > On 28 April 2011 17:13, Sassan Panahinejad > wrote: > > It should be possible for guest applications to fstat a file for > which they have a valid file descriptor, even if the file has been > removed. > Demonstrated by the code sample below (fstat reports no such file > or directory). > Strangely it seems that reading from a file in this state works > fine (and when both are run, the server receives a different fid > for each). > On any other filesystem, the code runs correctly. On our 9p > filesystem it fails. > Many applications (including bash) depend on this working correctly. > I will continue investigating, but any thoughts anyone has on the > subject would be appreciated. > > > Thanks > Sassan > > > #include > #include > #include > #include > #include > > > int main(void) > { > int ret; > struct stat statbuf; > int fd = open("test.txt", O_RDWR | O_CREAT, 0666); > if (fd < 0) { > printf("open failed: %m\n"); > return 1; > } > ret = write(fd, "test1\n", 6); > if (ret < 0) { > printf("write1 failed: %m\n"); > return 1; > } > ret = unlink("test.txt"); > if (ret < 0) { > printf("unlink failed: %m\n"); > return 1; > } > ret = fstat(fd, &statbuf); > if (ret < 0) { > printf("fstat failed: %m\n"); > return 1; > } > return 0; > } > > --------------010900050006040804010909 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 04/28/2011 09:51 AM, Sassan Panahinejad wrote:
This thread seems relevant: http://www.mail-archive.com/linux-fsdevel@vger.kernel.org/msg09159.html
Unless things have changed, it looks like the problem is in the client kernel (although note that there isn't support in qemu, even if the client did send an fid associated with an open file!).
Any thoughts on a workaround for this?

Hrm, I don't see any workaround for this. May be we should add TFSTAT for dotl? or add a flag to
TSTAT?

Copying the v9fs.

Thanks,
JV




Thanks
Sassan

On 28 April 2011 17:13, Sassan Panahinejad <sassan@sassan.me.uk> wrote:
It should be possible for guest applications to fstat a file for which they have a valid file descriptor, even if the file has been removed.
Demonstrated by the code sample below (fstat reports no such file or directory).
Strangely it seems that reading from a file in this state works fine (and when both are run, the server receives a different fid for each).
On any other filesystem, the code runs correctly. On our 9p filesystem it fails.
Many applications (including bash) depend on this working correctly.
I will continue investigating, but any thoughts anyone has on the subject would be appreciated.


Thanks
Sassan


#include <stdio.h>
#include <unistd.h>
#include <fcntl.h>
#include <sys/types.h>
#include <sys/stat.h>


int main(void)
{
        int ret;
        struct stat statbuf;
        int fd = open("test.txt", O_RDWR | O_CREAT, 0666);
        if (fd < 0) {
                printf("open failed: %m\n");
                return 1;
        }
        ret = write(fd, "test1\n", 6);
        if (ret < 0) {
                printf("write1 failed: %m\n");
                return 1;
        }
        ret = unlink("test.txt");
        if (ret < 0) {
                printf("unlink failed: %m\n");
                return 1;
        }
        ret = fstat(fd, &statbuf);
        if (ret < 0) {
                printf("fstat failed: %m\n");
                return 1;
        }
        return 0;
}


--------------010900050006040804010909--