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

[Peter Crosthwaite]

On Fri, Jun 22, 2012 at 5:49 PM, Kevin Wolf <address@hidden> 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 <address@hidden>
>
> 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?

>
> The assumption here is not that the block layer owns the coroutine, but
> that any code running in a coroutine can yield

Yield to who tho? A coroutine yield transfers control back to the
context that spawned it. For correct functionality, the block layer
should yielf back to whatever context called it no? Which would mean
that the the block layer when yielding should transfer back to
pflash_cfi_01_register. But because it was called from a coroutine in
the first place, it yields control all the way back my machine model
(which then breaks).

at any time as long at it
> makes sure that eventually the coroutine is reentered. Just like if you
> were running in a thread, you certainly wouldn't assume that the block
> layer has to create its own thread if it could get preempted, would you?
>
> Can you post some example code that explains the race conditions you're
> talking about?
>
> Kevin