qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [RFC PATCH 0/5] Removal of AioContext lock, bs->parents and ->childr


From: Vladimir Sementsov-Ogievskiy
Subject: Re: [RFC PATCH 0/5] Removal of AioContext lock, bs->parents and ->children: proof of concept
Date: Mon, 21 Mar 2022 15:22:19 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0

17.03.2022 00:55, Emanuele Giuseppe Esposito wrote:


Am 09/03/2022 um 14:26 schrieb Emanuele Giuseppe Esposito:
Next, I have a problem in mind, that in past lead to a lot of iotest 30
failures. Next there were different fixes and improvements, but the core
problem (as far as I understand) is still here: nothing protects us when
we are in some graph modification process (for example block-job
finalization) do yield, switch to other coroutine and enter another
graph modification process (for example, another block-job finaliztion)..
That's another point to consider. I don't really have a solution for this.

On a side note, that might not be a real problem.
If I understand correctly, your fear is that we are doing something like
parent->children[x] = new_node // partial graph operation
/* yield to another coroutine */
coroutine reads/writes parent->children[x] and/or new_node->parents[y]
/* yield back */
new_node->parents[y] = parent // end of the initial graph operation

Is that what you are pointing out here?
If so, is there a concrete example for this? Because yields and drains
(that eventually can poll) seem to be put either before or after the
whole graph modification section. In other words, even if a coroutine
enters, it will be always before or after the _whole_ graph modification
is performed.


The old example was here: 
https://lists.gnu.org/archive/html/qemu-devel/2020-11/msg05212.html  - not sure 
how much is it applicable now.

Another example - look at bdrv_drop_intermediate() in block.c and at TODO 
comments in it.

In both cases the problem is we want to update some metadata in qcow2 (backing 
file name) as part of block-graph modification. But this update does write to 
qcow2 header which may yield and switch to some another block-graph 
modification code.


--
Best regards,
Vladimir



reply via email to

[Prev in Thread] Current Thread [Next in Thread]