Now on the shared offset it wants shared_perm_lock_bits=18446744073709551594
That seems like an error, maybe by gdb displaying ?
Almost looks like the inverse (but later code path shows it is the absolute value e.g. index 0 is skipped):
Absolute would be:
BLK_PERM_WRITE
BLK_PERM_RESIZE
raw_apply_lock_bytes completes and returns 0
raw_handle_perm_lock continues
It enters raw_check_lock_bytes which verifies the success of the former action.
It essentially has the same loops but with qemu_lock_fd_test instead of qemu_lock_fd
The backtrace shows that it passes the child relationships of the images
bdrv_reopen_prepare -> bdrv_child_check_perm -> bdrv_check_update_perm -> bdrv_child_check_perm (loop back to bdrv_check_update_perm)
Until it reaches the base backing store.
The failing one is (as expected by the error) the write lock, but now we know it is the shared one:
(gdb) p off
$58 = 201
As we discussed here before, the assumption is that it won't need the write lock here.
Interestingly the error messages are off by one, the check for RAW_LOCK_SHARED_BASE reports
"Failed to get \"%s\" lock",
And the check to RAW_LOCK_PERM_BASE
"Failed to get shared \"%s\" lock",
Shouldn't that be vice-versa?
Anyway we know in which code to look for now.
#0 raw_handle_ perm_lock (bs=0x560aad12b550, op=RAW_PL_PREPARE, new_perm=11, new_shared=21, errp=0x7ffc6ff5 4090) at ./block/ file-posix. c:722 entry=0x560aad1 2b550, q=0x560aadd834a0, q@entry= 0x90af93e91d77c 000, cumulative_ perms=11, cumulative_ shared_ perms=< optimized out>, children= ignore_ children@ entry=0x560aad0 c7e70, errp=errp@ entry=0x7ffc6ff 54090) at ./block.c:1655 update_ perm (bs=0x560aad12b550, q=0x90af93e91d7 7c000, q@entry= 0x560aadd834a0, new_used_ perm=new_ used_perm@ entry=11, shared_ perm=new_ shared_ perm@entry= 21, ignore_ children= ignore_ children@ entry=0x560aad0 c7e70, errp=errp@ entry=0x7ffc6ff 54090) at ./block.c:1841 check_perm (errp=0x7ffc6ff 54090, ignore_ children= 0x560aad0c7e70, shared=<optimized out>, perm=11, q=0x560aadd834a0, c=0x560aad0566a0) at ./block.c:1854 0x90af93e91d77c 000, cumulative_perms=1, cumulative_ shared_ perms=21, children= ignore_ children@ entry=0x560aad0 3e700, errp=0x7ffc6ff5 4090, errp@entry=0x15) at ./block.c:1671 update_ perm (bs=0xb, q=0x90af93e91d7 7c000, q@entry= 0x560aadd834a0, new_used_ perm=new_ used_perm@ entry=1, new_shared_ perm=new_ shared_ perm@entry= 21, children= ignore_ children@ entry=0x560aad0 3e700, errp=0x15, errp@entry= 0x7ffc6ff54090) at ./block.c:1841 check_perm (errp=0x7ffc6ff 54090, ignore_ children= 0x560aad03e700, shared=<optimized out>, perm=1, q=0x560aadd834a0, c=0x560aad06e800) at ./block.c:1854 0x90af93e91d77c 000, cumulative_perms=1, cumulative_ shared_ perms=21, children= ignore_ children@ entry=0x560aad0 3e570, errp=0x7ffc6ff5 4090, errp@entry=0x15) at ./block.c:1671 update_ perm (bs=0x1, q=0x90af93e91d7 7c000, q@entry= 0x560aadd834a0, new_used_ perm=new_ used_perm@ entry=1, new_shared_ perm=new_ shared_ perm@entry= 21, children= ignore_ children@ entry=0x560aad0 3e570, errp=0x15, errp@entry= 0x7ffc6ff54090) at ./block.c:1841 check_perm (errp=0x7ffc6ff 54090, ignore_ children= 0x560aad03e570, shared=<optimized out>, perm=1, q=0x560aadd834a0, c=0x560aad03e200) at ./block.c:1854 0x560aadd834a0, cumulative_perms=1, cumulative_ shared_ perms=21, ignore_ children= ignore_ children@ entry=0x0, errp=errp@ entry=0x7ffc6ff 54090) state=reopen_ state@entry= 0x560aadd83418, queue=queue@ entry=0x560aadd 834a0, errp=errp@ entry=0x7ffc6ff 54090) at ./block.c:3111 multiple (ctx=<optimized out>, bs_queue= 0x560aadd834a0, errp=errp@ entry=0x7ffc6ff 540f0) at ./block.c:2887 entry=0x560aad0 e53d0, bdrv_flags= <optimized out>, errp=errp@ entry=0x7ffc6ff 541f0) at ./block.c:2928 job_id@ entry=0x0, bs=bs@entry= 0x560aadf47890, base=base@ entry=0x560aad0 e53d0, creation_ flags=creation_ flags@entry= 0, speed@entry= 0, on_error= on_error@ entry=BLOCKDEV_ ON_ERROR_ REPORT, filter_ node_name= 0x0, cb=0x0, opaque=0x0, auto_complete= false, errp=0x7ffc6ff5 41f0) at ./block/ mirror. c:1311 id=<optimized out>, job_id=0x0, device=<optimized out>, has_base=<optimized out>, base=<optimized out>, has_top=<optimized out>, file=false, backing_file=0x0, has_speed=false, speed=0, has_filter_ node_name= false, filter_ node_name= 0x0, errp=0x7ffc6ff5 4288) at ./blockdev.c:3150 block_commit (args=<optimized out>, ret=<optimized out>, errp=0x7ffc6ff5 4348) at qmp-marshal.c:168
#1 0x0000560aac2b9e8e in bdrv_check_perm (bs=bs@
ignore_
#2 0x0000560aac2b9d05 in bdrv_check_
new_
#3 0x0000560aac2b9f54 in bdrv_child_
#4 bdrv_check_perm (bs=0x560aad125250, bs@entry=0xb, q=0x560aadd834a0, q@entry=
ignore_
#5 0x0000560aac2b9d05 in bdrv_check_
ignore_
#6 0x0000560aac2b9f54 in bdrv_child_
#7 bdrv_check_perm (bs=0x560aad105750, bs@entry=0x1, q=0x560aadd834a0, q@entry=
ignore_
#8 0x0000560aac2b9d05 in bdrv_check_
ignore_
#9 0x0000560aac2b9f54 in bdrv_child_
#10 bdrv_check_perm (bs=0x560aad0e53d0, q=q@entry=
at ./block.c:1671
#11 0x0000560aac2bb7ea in bdrv_reopen_prepare (reopen_
#12 0x0000560aac2bb94f in bdrv_reopen_
#13 0x0000560aac2bbacf in bdrv_reopen (bs=bs@
#14 0x0000560aac306f3e in commit_active_start (job_id=
speed=
#15 0x0000560aac0cf30a in qmp_block_commit (has_job_
top=0x0, has_backing_
#16 0x0000560aac0d9d2e in qmp_marshal_
(gdb) p s->lock_fd
$2 = 18
root@b:~# ll /proc/5942/fd/18
lr-x------ 1 root root 64 Jul 30 06:45 /proc/5942/fd/18 -> /root/base.qcow2
(gdb) p op
$3 = RAW_PL_PREPARE
(gdb) p ~s->shared_perm | ~new_shared 51594 51594
$7 = 184467440737095
(gdb) p ~(s->shared_perm) | ~new_shared
$8 = 184467440737095
goes into lock_bytes (s=s@entry= 0x560aad112ab0, perm_lock_bits=11, shared_ perm_lock_ bits=1844674407 3709551594, unlock= unlock@ entry=false, errp=errp@ entry=0x7ffc6ff 54090)
raw_apply_
qemu_lock_fd (fd=18, start=100, len=1, exclusive=false) at ./util/osdep.c:255
qemu_lock_fcntl (fd=18, start=100, len=1, fl_type=0) at ./util/osdep.c:238
The first round on RAW_LOCK_PERM_BASE all succeed.
Value was 11 which is
BLK_PERM_ CONSISTENT_ READ
BLK_PERM_WRITE
BLK_PERM_RESIZE
Now on the shared offset it wants shared_ perm_lock_ bits=1844674407 3709551594
That seems like an error, maybe by gdb displaying ?
Almost looks like the inverse (but later code path shows it is the absolute value e.g. index 0 is skipped):
Absolute would be:
BLK_PERM_WRITE
BLK_PERM_RESIZE
raw_apply_ lock_bytes completes and returns 0 perm_lock continues
raw_handle_
It enters raw_check_ lock_bytes which verifies the success of the former action.
It essentially has the same loops but with qemu_lock_fd_test instead of qemu_lock_fd
The backtrace shows that it passes the child relationships of the images
bdrv_reopen_prepare -> bdrv_child_ check_perm -> bdrv_check_ update_ perm -> bdrv_child_ check_perm (loop back to bdrv_check_ update_ perm)
Until it reaches the base backing store.
The failing one is (as expected by the error) the write lock, but now we know it is the shared one:
(gdb) p off
$58 = 201
As we discussed here before, the assumption is that it won't need the write lock here. SHARED_ BASE reports
Interestingly the error messages are off by one, the check for RAW_LOCK_
"Failed to get \"%s\" lock",
And the check to RAW_LOCK_PERM_BASE
"Failed to get shared \"%s\" lock",
Shouldn't that be vice-versa?
Anyway we know in which code to look for now.