diff options
| author | Fam Zheng | 2017-08-11 13:44:47 +0200 |
|---|---|---|
| committer | Kevin Wolf | 2017-08-11 14:12:44 +0200 |
| commit | 2b218f5dbcca5fe728b1852d161d7a21fd02b2f5 (patch) | |
| tree | 515a8cbe2767282a5bf6f33eac20cde3cc0264a4 /include/qapi/string-input-visitor.h | |
| parent | osdep: Add runtime OFD lock detection (diff) | |
| download | qemu-2b218f5dbcca5fe728b1852d161d7a21fd02b2f5.tar.gz qemu-2b218f5dbcca5fe728b1852d161d7a21fd02b2f5.tar.xz qemu-2b218f5dbcca5fe728b1852d161d7a21fd02b2f5.zip | |
file-posix: Do runtime check for ofd lock API
It is reported that on Windows Subsystem for Linux, ofd operations fail
with -EINVAL. In other words, QEMU binary built with system headers that
exports F_OFD_SETLK doesn't necessarily run in an environment that
actually supports it:
$ qemu-system-aarch64 ... -drive file=test.vhdx,if=none,id=hd0 \
-device virtio-blk-pci,drive=hd0
qemu-system-aarch64: -drive file=test.vhdx,if=none,id=hd0: Failed to unlock byte 100
qemu-system-aarch64: -drive file=test.vhdx,if=none,id=hd0: Failed to unlock byte 100
qemu-system-aarch64: -drive file=test.vhdx,if=none,id=hd0: Failed to lock byte 100
As a matter of fact this is not WSL specific. It can happen when running
a QEMU compiled against a newer glibc on an older kernel, such as in
a containerized environment.
Let's do a runtime check to cope with that.
Reported-by: Andrew Baumann <Andrew.Baumann@microsoft.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Fam Zheng <famz@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Diffstat (limited to 'include/qapi/string-input-visitor.h')
0 files changed, 0 insertions, 0 deletions