qemu-img --force-share does not disable file locking
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
QEMU |
Invalid
|
Undecided
|
Unassigned |
Bug Description
The new option "--force-share" for qemu-img does not disable file locking.
I tried it with version qemu-img version 2.11.1(Debian 1:2.11+
Sample to demonstrate:
# strace qemu-img info --force-share testfile.qcow2 2>&1 | grep F_RDLCK
fcntl(11, F_OFD_SETLK, {l_type=F_RDLCK, l_whence=SEEK_SET, l_start=100, l_len=1}) = 0
fcntl(11, F_OFD_SETLK, {l_type=F_RDLCK, l_whence=SEEK_SET, l_start=100, l_len=1}) = 0
fcntl(11, F_OFD_SETLK, {l_type=F_RDLCK, l_whence=SEEK_SET, l_start=100, l_len=1}) = 0
fcntl(11, F_OFD_SETLK, {l_type=F_RDLCK, l_whence=SEEK_SET, l_start=100, l_len=1}) = 0
fcntl(11, F_OFD_SETLK, {l_type=F_RDLCK, l_whence=SEEK_SET, l_start=100, l_len=1}) = 0
fcntl(11, F_OFD_SETLK, {l_type=F_RDLCK, l_whence=SEEK_SET, l_start=100, l_len=1}) = 0
fcntl(11, F_OFD_SETLK, {l_type=F_RDLCK, l_whence=SEEK_SET, l_start=100, l_len=1}) = 0
fcntl(11, F_OFD_SETLK, {l_type=F_RDLCK, l_whence=SEEK_SET, l_start=100, l_len=1}) = 0
fcntl(11, F_OFD_SETLK, {l_type=F_RDLCK, l_whence=SEEK_SET, l_start=100, l_len=1}) = 0
I traced the passing of the --force-share option through the source code (I used commit 6c599282f8 as of Mon Feb 17 13:32:25 2020 +0000)
qemu-img.
force_share = true;
qemu-img.
qemu-img.
qemu-img.
block/block-
block.c:
block.c:
block.c:
block.c:
include/
block/file-
block/file-
locking = qapi_enum_
ignoring bs->force_share
At the end, bs->force_share is ignored in determining the locking value.
Hi,
That’s intentional. The man page says this:
If specified, "qemu-img" will open the image in shared mode,
allowing other QEMU processes to open it in write mode. For
example, this can be used to get the image information (with
'info' subcommand) when the image is used by a running guest.
It says nothing about not using file locks. All it will do is cause qemu-img to signal to other processes that it’s OK for them to use the image in any way, or if there already is another process having opened the image for any access, qemu-img will not complain.
For example, open a qemu-io process on some image:
$ qemu-io foo.qcow2
And in another shell, invoke qemu-img:
$ qemu-img info foo.qcow2
qemu-img: Could not open 'foo.qcow2': Failed to get shared "write" lock
Is another process using the image [foo.qcow2]?
$ qemu-img info --force-share foo.qcow2
image: foo.qcow2
file format: qcow2
[...]
force-share is evaluated in bdrv_child_perm in block.c. The file locks qemu sets are an extension of the internal “permission” system we use for block nodes: For example, when some guest device wants write access to an image, it has to take the WRITE permission. That will be disallowed if there is some other user of the image that does not allow taking the WRITE permission (we say: it “unshares” the WRITE permission). force-share enforces sharing all permissions, but it does not disable the permission system.
The file locks are used to transmit that internal mechanism of taking/sharing permissions across different processes. Unshared permissions are reflected by locks between offset 200 and 299. Taken permissions are reflected by locks between offset 100 and 199. As you can see, qemu-img with --force-share does not unshare any permissions (it does not take any locks after offset 200). The only lock it takes is offset 100, which corresponds to CONSISTENT_READ. That permission means “I want to read from the image and get back something sane”. So if any other process uses the image in such a way that this is impossible (i.e., it has to unshare CONSISTENT_READ), qemu-img info will complain, regardless of --force-share.
File locks can only be completely disabled through file-posix’s @locking option (locking=false), e.g. like so:
$ qemu-img info --image-opts file.filename= foo.qcow2, file.locking= off
But that is strongly discouraged, and I have yet to see a case where this would be the right thing to do.
Max