Re: [Qemu-devel] [RFC] block: Removed coroutine ownership assumption

[Kevin Wolf <kwolf@redhat.com>]

Am 22.06.2012 10:20, schrieb Peter Crosthwaite:
> On Fri, Jun 22, 2012 at 5:49 PM, Kevin Wolf <kwolf@redhat.com> wrote:
>> Am 22.06.2012 08:44, schrieb Peter A. G. Crosthwaite:
>>> The block layer assumes that it is the only user of coroutines -
>>> The qemu_in_coroutine() is used to determine if a function is in one of the
>>> block layers coroutines, which is flawed. I.E. If a client (e.g. a device or
>>> a machine model) of the block layer uses couroutine itself, the block layer
>>> will identify the callers coroutines as its own, and may falsely yield the
>>> calling coroutine (instead of creating its own to yield).
>>>
>>> AFAICT, there are no conflicts in the QEMU master here yet, but its kind of an
>>> issue, as anyone who comes along and used coroutines and the block layer
>>> together is going to run into some very obscure and hard to debug race
>>> conditions.
>>>
>>> Signed-off-by: Peter A. G. Crosthwaite <peter.crosthwaite@petalogix.com>
>>
>> What does your coroutine caller look like that this is a problem?
> 
> Its a machine model that instantiated some block devices concurrently.
> Theres some chicken-and-egg issues with the instantiation such that
> they have the happen concurrently. One device instantiates a block
> device (pflash_cfi_01) from coroutine context. block then check
> qemu_in_coroutine() which returns true so it uses my coroutine for its
> inner workings, whereas if it were a normal machine model it would
> kick of its own coroutine to do its block stuff.
> 
>  Does
>> it make assumptions about the number of yields or anything like that?
> 
> Yes it does, but I thought that was the point of coroutines vs
> threads? coroutines you control yield behaviour explicitly whearas
> thread you cant?

Well, I can see your point, although today no code in qemu makes use of
the property that the caller could in theory know where the coroutine
yields. I think it's also dangerous because there is a non-obvious
dependency of the caller on the internals of the coroutine. A simple
innocent looking refactoring of the coroutine might break assumptions
that are made here.

Other code in qemu that uses coroutines only makes use of the fact that
coroutines can only be interrupted at known points, so synchronisation
between multiple coroutines becomes easier.

Kevin