Re: [RFC PATCH v2 0/8] Removal of AioContext lock, bs->parents and ->children: new rwlock

[Paolo Bonzini]

On 5/2/22 10:02, Emanuele Giuseppe Esposito wrote:
> > Are you saying rdlock isn't necessary in the main loop because nothing
> > can take the wrlock while our code is executing in the main loop?
> Yes, that's the idea.
> If I am not mistaken (and I hope I am not), only the main loop currently
> modifies/is allowed to modify the graph.
>
> The only case where currently we need to take the rdlock in main loop is
> when we have the case
>
> simplified_flush_callback(bs) {
>         for (child in bs)
>                 bdrv_flush(child->bs);
> }
>
> some_function() {
>         GLOBAL_STATE_CODE();
>         /* assume bdrv_get_aio_context(bs) != qemu_in_main_thread() */
>
>         bdrv_flush(bs);
>                 co = coroutine_create(bdrv_get_aio_context(bs))
>                 qemu_coroutine_enter(co, simplified_flush_callback)
> }

This is correct, but it is very unsafe as long as bdrv_flush(bs) is 
allowed to run both in coroutine context and outside.  So we go circling 
back to the same issue that was there in the stackless coroutine 
experiment, i.e. functions that can run both in coroutine context and 
outside.

This issue is fundamentally one of unclear invariants, and reminds me a 
lot of the problems with recursive mutexes.

Paolo