[Bug 1905979] Re: Check if F_OFD_SETLK is supported may give wrong result

[Olaf Seibert <1905979@bugs.launchpad.net>]

Interesting. Thanks for the link.

The file system we are using is the Quobyte file system (2.24.1) (https://www.quobyte.com/), which works via FUSE. 
We've had problems with OFD locks with this file system in the past, so my first thought, seeing the error in comment #1, was that those would be to blame.

But if the OFD locks are not really handled by the file system, I'm not
sure how that explains the OFD lock issues we had in the past. I don't
suppose this changed in the last year or so. Just now I made a little
test program (basically copying qemu_lock_fd_test() and
qemu_probe_lock_ops() from qemu) to double-check, and indeed right now
it seems that the OFD locks *are* working on the Quobyte file system. Or
at least qemu_lock_fd_test() doesn't return an error.

So now I'm back to square one on diagnosing the observed error. It
occurred in an installation of Openstack Ussuri installed on Ubuntu
18.04 Bionic using the Ubuntu Cloud Archive for packaging. The Cloud
Archive has backports of the latest Qemu to earlier Ubuntu versions. The
exact qemu version was http://ubuntu-
cloud.archive.canonical.com/ubuntu/pool/main/q/qemu/qemu_4.2-3ubuntu6.7~cloud0_amd64.deb
.

Annoyingly I have not been able to locate the git repo from which the
Ubuntu Cloud Archive creates its packages (containing the patches and
build changes for backports); all I can find is version 4.2-3ubuntu6.7
(without ~cloud0) which is for Ubuntu 20.04 Focal.

For now we're working around it by downgrading Qemu to the normal Bionic
version (2.11+dfsg-1ubuntu7.33)

You wouldn't happen to know where the Ubuntu Cloud Archive stores exact
files it creates its packages from? (I have already asked on
stackoverflow without success so far:
https://stackoverflow.com/questions/65146846/from-which-git-repos-does-
the-ubuntu-cloud-archive-compile-its-packages)

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1905979

Title:
  Check if F_OFD_SETLK is supported may give wrong result

Status in QEMU:
  Incomplete

Bug description:
  In util/osdep.c there is a function qemu_probe_lock_ops() to check if
  file locks F_OFD_SETLK and F_OFD_GETLK (of the style "Open file
  description locks (non-POSIX)") are supported.

  This test is done by trying a lock operation on the file /dev/null.

  This test can get a wrong result.

  The result is (probably) if the operating system *in general* supports
  these locks. However, it does not guarantee that the file system where
  the lock is really wanted (for instance, in caller
  raw_check_lock_bytes() in block/file-posix.c) does support these
  locks.

  (In theory it could even be that /dev/null, being a device special
  file, does not support the lock type while a plain file would.)

  This is in particular relevant for disk images which are stored on a
  shared file system (my particular use case is the Quobyte file system,
  which appears not to support these locks).

  The code as mentioned above is present in the master branch (I checked
  commit ea8208249d1082eae0444934efb3b59cd3183f05) but also for example
  on stable-2.11 commit 0982a56a551556c704dc15752dabf57b4be1c640)

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1905979/+subscriptions