In our multipath case, the initial open succeeds (it's not locked by anything else) and the second lock attempt fails, however, IIUC the fcntl structure[1] includes the locking pid, which should be our invocation of QEMU;
Can we not check if the locking pid matches the current pid and not fail? This appears to be the original goal of protecting locked images from being manipulated by external processes. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1716028 Title: qemu 2.10 locks images with no feature flag To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1716028/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
