All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
To: "Daniel P. Berrange" <berrange@redhat.com>, qemu-devel@nongnu.org
Cc: qemu-trivial@nongnu.org,
	"Daniel P. Berrange" <berrange@redhat.com>,
	Anthony Liguori <anthony@codemonkey.ws>
Subject: Re: [Qemu-trivial] [PATCH] hw/9pfs: Fix errno value for xattr functions
Date: Tue, 01 Oct 2013 21:53:20 +0530	[thread overview]
Message-ID: <87li2dc64n.fsf@linux.vnet.ibm.com> (raw)
In-Reply-To: <1380626897-500-1-git-send-email-berrange@redhat.com>

"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



WARNING: multiple messages have this Message-ID (diff)
From: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
To: "Daniel P. Berrange" <berrange@redhat.com>, qemu-devel@nongnu.org
Cc: qemu-trivial@nongnu.org, Anthony Liguori <anthony@codemonkey.ws>
Subject: Re: [Qemu-devel] [PATCH] hw/9pfs: Fix errno value for xattr functions
Date: Tue, 01 Oct 2013 21:53:20 +0530	[thread overview]
Message-ID: <87li2dc64n.fsf@linux.vnet.ibm.com> (raw)
In-Reply-To: <1380626897-500-1-git-send-email-berrange@redhat.com>

"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

  reply	other threads:[~2013-10-02  9:55 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-10-01 11:28 [Qemu-trivial] [PATCH] hw/9pfs: Fix errno value for xattr functions Daniel P. Berrange
2013-10-01 11:28 ` [Qemu-devel] " Daniel P. Berrange
2013-10-01 16:23 ` Aneesh Kumar K.V [this message]
2013-10-01 16:23   ` Aneesh Kumar K.V
2013-10-02 16:36 ` [Qemu-trivial] " Michael Tokarev
2013-10-02 16:36   ` [Qemu-devel] " Michael Tokarev

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87li2dc64n.fsf@linux.vnet.ibm.com \
    --to=aneesh.kumar@linux.vnet.ibm.com \
    --cc=anthony@codemonkey.ws \
    --cc=berrange@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-trivial@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.