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 Let's do a runtime check to cope with that. Reported-by: Andrew Baumann <andrew.baum...@microsoft.com> Signed-off-by: Fam Zheng <f...@redhat.com> --- block/file-posix.c | 19 ++++++++----------- 1 file changed, 8 insertions(+), 11 deletions(-) diff --git a/block/file-posix.c b/block/file-posix.c index cfbb236f6f..5ddf2729eb 100644 --- a/block/file-posix.c +++ b/block/file-posix.c @@ -457,22 +457,19 @@ static int raw_open_common(BlockDriverState *bs, QDict *options, 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(); -- 2.13.3