On 11/15/21 17:03, Hanna Reitz wrote:
I only really see four solutions for this:
(1) We somehow make the amend job run in the main context under the BQL
and have it prevent all concurrent I/O access (seems bad)
(2) We can make the permission functions part of the I/O path (seems
wrong and probably impossible?)
(3) We can drop the permissions update and permanently require the
permissions that we need when updating keys (I think this might break
existing use cases)
(4) We can acquire the BQL around the permission update call and perhaps
that works?
I don’t know how (4) would work but it’s basically the only reasonable
solution I can come up with. Would this be a way to call a BQL function
from an I/O function?
I think that would deadlock:
main I/O thread
-------- -----
start bdrv_co_amend
take BQL
bdrv_drain
... hangs ...
(2) is definitely wrong.
(3) I have no idea.
Would it be possible or meaningful to do the bdrv_child_refresh_perms in
qmp_x_blockdev_amend? It seems that all users need it, and in general
it seems weird to amend a qcow2 or luks header (and thus the meaning of
parts of the file) while others can write to the same file.
Paolo