Re: Question about graph locking preconditions regarding qemu_in_main_thread()

[Fiona Ebner <f.ebner@proxmox.com>]

Am 09.05.23 um 15:53 schrieb Kevin Wolf:
> Am 09.05.2023 um 12:26 hat Fiona Ebner geschrieben:
>> Am 08.05.23 um 12:40 schrieb Kevin Wolf:
>>> Am 05.05.2023 um 11:35 hat Fiona Ebner geschrieben:
>>>> Hi,
>>>> I noticed that the bdrv_graph_co_rd_lock() and bdrv_graph_co_rd_unlock()
>>>> functions use qemu_in_main_thread() as a conditional to return early.
>>>> What high-level requirements ensure that qemu_in_main_thread() will
>>>> evaluate to the same value during locking and unlocking?
>>>
>>> I think it's actually wrong.
>>>
>>> There are some conditions under which we don't actually need to do
>>> anything for locking: Writing the graph is only possible from the main
>>> context while holding the BQL. So if a reader is running in the main
>>> contextunder the BQL and knows that it won't be interrupted until the
>>> next writer runs, we don't actually need to do anything.
>>>
>>> This is the case if the reader code neither has a nested event loop
>>> (this is forbidden anyway while you hold the lock) nor is a coroutine
>>> (because a writer could run when the coroutine has yielded).
>>
>> Sorry, I don't understand the first part. If bdrv_writev_vmstate() is
>> called, then, because it is a generated coroutine wrapper,
>> AIO_WAIT_WHILE()/aio_poll() is used. And that is the case regardless of
>> whether the lock is held or not, i.e. there is a nested event loop even
>> if the lock is held?
> 
> With "lock" you mean the graph lock here, not the BQL, right?

Oh, I actually meant the BQL. Since your "lock" refers to the graph
lock, that explains my confusion :)

> 
> These generated coroutine wrapper are a bit ugly because they behave
> different when called from a coroutine and when called outside of
> coroutine context:
> 
> * In coroutine context, the caller MUST hold the lock
> * Outside of coroutine context, the caller MUST NOT hold the lock
> 
> The second requirement comes from AIO_WAIT_WHILE(), like you say. If you
> hold the lock and you're not in a coroutine, you simply can't call such
> functions.
> 
> However, as bdrv_graph_co_rdlock() is a coroutine_fn, you won't usually
> hold the lock outside of coroutine context anyway. But it's something to
> be careful with when you have a writer lock.
> 

Best Regards,
Fiona