diff mbox

hw/9pfs: Fix errno value for xattr functions

Message ID 1380626897-500-1-git-send-email-berrange@redhat.com
State New
Headers show

Commit Message

Daniel P. Berrangé Oct. 1, 2013, 11:28 a.m. UTC
From: "Daniel P. Berrange" <berrange@redhat.com>

If there is no operation driver for the xattr type the
functions return '-1' and set errno to '-EOPNOTSUPP'.
When the calling code sets 'ret = -errno' this turns
into a large positive number.

In Linux 3.11, the kernel has switched to using 9p
version 9p2000.L, instead of 9p2000.u, which enables
support for xattr operations. This on its own is harmless,
but for another change which makes it request the xattr
with a name 'security.capability'.

The result is that the guest sees a succesful return
of 95 bytes of data, instead of a failure with errno
set to 95. Since the kernel expects a maximum of 20
bytes for an xattr return this gets translated to the
unexpected errno ERANGE.

This all means that when running a binary off a 9p fs
in 3.11 kernels you get a fun result of:

  # ./date
  sh: ./date: Numerical result out of range

The only workaround is to pass 'version=9p2000.u' when
mounting the 9p fs in the guest, to disable all use of
xattrs.

Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
---
 hw/9pfs/virtio-9p-xattr.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

Comments

Aneesh Kumar K.V Oct. 1, 2013, 4:23 p.m. UTC | #1
"Daniel P. Berrange" <berrange@redhat.com> writes:

> From: "Daniel P. Berrange" <berrange@redhat.com>
>
> If there is no operation driver for the xattr type the
> functions return '-1' and set errno to '-EOPNOTSUPP'.
> When the calling code sets 'ret = -errno' this turns
> into a large positive number.
>
> In Linux 3.11, the kernel has switched to using 9p
> version 9p2000.L, instead of 9p2000.u, which enables
> support for xattr operations. This on its own is harmless,
> but for another change which makes it request the xattr
> with a name 'security.capability'.
>
> The result is that the guest sees a succesful return
> of 95 bytes of data, instead of a failure with errno
> set to 95. Since the kernel expects a maximum of 20
> bytes for an xattr return this gets translated to the
> unexpected errno ERANGE.
>
> This all means that when running a binary off a 9p fs
> in 3.11 kernels you get a fun result of:
>
>   # ./date
>   sh: ./date: Numerical result out of range
>
> The only workaround is to pass 'version=9p2000.u' when
> mounting the 9p fs in the guest, to disable all use of
> xattrs.
>
> Signed-off-by: Daniel P. Berrange <berrange@redhat.com>


Reviewed-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>

> ---
>  hw/9pfs/virtio-9p-xattr.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/hw/9pfs/virtio-9p-xattr.c b/hw/9pfs/virtio-9p-xattr.c
> index 90ae565..3fae557 100644
> --- a/hw/9pfs/virtio-9p-xattr.c
> +++ b/hw/9pfs/virtio-9p-xattr.c
> @@ -36,7 +36,7 @@ ssize_t v9fs_get_xattr(FsContext *ctx, const char *path,
>      if (xops) {
>          return xops->getxattr(ctx, path, name, value, size);
>      }
> -    errno = -EOPNOTSUPP;
> +    errno = EOPNOTSUPP;
>      return -1;
>  }
>
> @@ -123,7 +123,7 @@ int v9fs_set_xattr(FsContext *ctx, const char *path, const char *name,
>      if (xops) {
>          return xops->setxattr(ctx, path, name, value, size, flags);
>      }
> -    errno = -EOPNOTSUPP;
> +    errno = EOPNOTSUPP;
>      return -1;
>
>  }
> @@ -135,7 +135,7 @@ int v9fs_remove_xattr(FsContext *ctx,
>      if (xops) {
>          return xops->removexattr(ctx, path, name);
>      }
> -    errno = -EOPNOTSUPP;
> +    errno = EOPNOTSUPP;
>      return -1;
>
>  }
> -- 
> 1.8.3.1
Michael Tokarev Oct. 2, 2013, 4:36 p.m. UTC | #2
01.10.2013 15:28, Daniel P. Berrange пишет:
> From: "Daniel P. Berrange" <berrange@redhat.com>
>
> If there is no operation driver for the xattr type the
> functions return '-1' and set errno to '-EOPNOTSUPP'.
> When the calling code sets 'ret = -errno' this turns
> into a large positive number.
>
> In Linux 3.11, the kernel has switched to using 9p
> version 9p2000.L, instead of 9p2000.u, which enables
> support for xattr operations. This on its own is harmless,
> but for another change which makes it request the xattr
> with a name 'security.capability'.
>
> The result is that the guest sees a succesful return
> of 95 bytes of data, instead of a failure with errno
> set to 95. Since the kernel expects a maximum of 20
> bytes for an xattr return this gets translated to the
> unexpected errno ERANGE.
>
> This all means that when running a binary off a 9p fs
> in 3.11 kernels you get a fun result of:
>
>    # ./date
>    sh: ./date: Numerical result out of range
>
> The only workaround is to pass 'version=9p2000.u' when
> mounting the 9p fs in the guest, to disable all use of
> xattrs.

Thanks, applied to the trivial patches queue.

/mjt
diff mbox

Patch

diff --git a/hw/9pfs/virtio-9p-xattr.c b/hw/9pfs/virtio-9p-xattr.c
index 90ae565..3fae557 100644
--- a/hw/9pfs/virtio-9p-xattr.c
+++ b/hw/9pfs/virtio-9p-xattr.c
@@ -36,7 +36,7 @@  ssize_t v9fs_get_xattr(FsContext *ctx, const char *path,
     if (xops) {
         return xops->getxattr(ctx, path, name, value, size);
     }
-    errno = -EOPNOTSUPP;
+    errno = EOPNOTSUPP;
     return -1;
 }
 
@@ -123,7 +123,7 @@  int v9fs_set_xattr(FsContext *ctx, const char *path, const char *name,
     if (xops) {
         return xops->setxattr(ctx, path, name, value, size, flags);
     }
-    errno = -EOPNOTSUPP;
+    errno = EOPNOTSUPP;
     return -1;
 
 }
@@ -135,7 +135,7 @@  int v9fs_remove_xattr(FsContext *ctx,
     if (xops) {
         return xops->removexattr(ctx, path, name);
     }
-    errno = -EOPNOTSUPP;
+    errno = EOPNOTSUPP;
     return -1;
 
 }