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

Reply via email to