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>
switch (locking) {
case ON_OFF_AUTO_ON:
s->use_lock = true;
-#ifndef F_OFD_SETLK
- fprintf(stderr,
- "File lock requested but OFD locking syscall is unavailable, "
- "falling back to POSIX file locks.\n"
- "Due to the implementation, locks can be lost unexpectedly.\n");
-#endif
+ if (!qemu_has_ofd_lock()) {
+ fprintf(stderr,
+ "File lock requested but OFD locking syscall is "
+ "unavailable, falling back to POSIX file locks.\n"
+ "Due to the implementation, locks can be lost "
+ "unexpectedly.\n");
+ }
break;
case ON_OFF_AUTO_OFF:
s->use_lock = false;
break;
case ON_OFF_AUTO_AUTO:
-#ifdef F_OFD_SETLK
- s->use_lock = true;
-#else
- s->use_lock = false;
-#endif
+ s->use_lock = qemu_has_ofd_lock();
break;
default:
abort();