summaryrefslogtreecommitdiff
path: root/util
diff options
context:
space:
mode:
authorDaniel P. Berrange <berrange@redhat.com>2013-10-01 12:28:17 +0100
committerMichael Tokarev <mjt@tls.msk.ru>2013-10-05 13:05:28 +0400
commit8af00205445eb901f17ca5b632d976065187538e (patch)
tree576645b778e5911f500ee5952877c5cb67c1483d /util
parente3fdc535f25b471e55ac3c8b9f0b504957015bbe (diff)
downloadqemu-8af00205445eb901f17ca5b632d976065187538e.tar.gz
hw/9pfs: Fix errno value for xattr functions
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> Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Diffstat (limited to 'util')
0 files changed, 0 insertions, 0 deletions