Re: [PATCH v4 00/25] block layer: split block APIs in global state and I/O

[Paolo Bonzini <pbonzini@redhat.com>]

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