[Qemu-devel] Bug in virtio-9p when fstatting an fd referring to a file that no longer exists

[Qemu-devel] Bug in virtio-9p when fstatting an fd referring to a file that no longer exists

[Sassan Panahinejad]

[-- Attachment #1: Type: text/plain, Size: 1401 bytes --]

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;
}

[-- Attachment #2: Type: text/html, Size: 1680 bytes --]

Re: [Qemu-devel] Bug in virtio-9p when fstatting an fd referring to a file that no longer exists

[Sassan Panahinejad]

[-- Attachment #1: Type: text/plain, Size: 1920 bytes --]

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?


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;
> }
>

[-- Attachment #2: Type: text/html, Size: 2482 bytes --]

Re: [Qemu-devel] Bug in virtio-9p when fstatting an fd referring to a file that no longer exists

[Venkateswararao Jujjuri]

[-- Attachment #1: Type: text/plain, Size: 2357 bytes --]

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 
> <mailto: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;
>     }
>
>


[-- Attachment #2: Type: text/html, Size: 5021 bytes --]

Re: [Qemu-devel] Bug in virtio-9p when fstatting an fd referring to a file that no longer exists

[Sassan Panahinejad]

[-- Attachment #1: Type: text/plain, Size: 2556 bytes --]

On 2 May 2011 16:47, Venkateswararao Jujjuri <jvrao@linux.vnet.ibm.com>wrote:

>  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?
>

It's definitely a tricky problem. I can't think of how to go about dealing
with it.
Probably worth looking into how nfs deals with it (and also looking into
what happens when communicating between two native plan9 systems). I'll
start reading.

Thanks
Sassan


>
> 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;
>> }
>>
>
>
>

[-- Attachment #2: Type: text/html, Size: 4557 bytes --]