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

[Vladimir Sementsov-Ogievskiy <v.sementsov-og@mail.ru>]

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