Am 25.05.2020 um 16:18 hat Stefan Reiter geschrieben: > On 5/12/20 4:43 PM, Kevin Wolf wrote: > > Coroutine functions that are entered through bdrv_run_co() are already > > safe to call from synchronous code in a different AioContext because > > bdrv_coroutine_enter() will schedule them in the context of the node. > > > > However, the coroutine fastpath still requires that we're already in the > > right AioContext when called in coroutine context. > > > > In order to make the behaviour more consistent and to make life a bit > > easier for callers, let's check the AioContext and automatically move > > the current coroutine around if we're not in the right context yet. > > > > Signed-off-by: Kevin Wolf <[email protected]> > > --- > > block/io.c | 15 ++++++++++++++- > > 1 file changed, 14 insertions(+), 1 deletion(-) > > > > diff --git a/block/io.c b/block/io.c > > index c1badaadc9..7808e8bdc0 100644 > > --- a/block/io.c > > +++ b/block/io.c > > @@ -895,8 +895,21 @@ static int bdrv_run_co(BlockDriverState *bs, > > CoroutineEntry *entry, > > void *opaque, int *ret) > > { > > if (qemu_in_coroutine()) { > > - /* Fast-path if already in coroutine context */ > > + Coroutine *self = qemu_coroutine_self(); > > + AioContext *bs_ctx = bdrv_get_aio_context(bs); > > + AioContext *co_ctx = qemu_coroutine_get_aio_context(self); > > + > > + if (bs_ctx != co_ctx) { > > + /* Move to the iothread of the node */ > > + aio_co_schedule(bs_ctx, self); > > + qemu_coroutine_yield(); > > I'm pretty sure this can lead to a race: When the thread we're re-scheduling > to is faster to schedule us than we can reach qemu_coroutine_yield, then > we'll get an abort ("Co-routine re-entered recursively"), since co->caller > is still set. > > I've seen this happen in our code when I try to do the scheduling fandangle > there.
Ah, crap. I guess letting a coroutine re-schedule itself is only safe within the same thread then. > Is there a safer way to have a coroutine reschedule itself? Some lock > missing? There is no problem that can't be solved by adding another level of indirection... We would have to schedule a BH in the original thread that will only schedule the coroutine in its new thread after it has yielded. Maybe we should actually introduce a helper function that moves the current coroutine to a different AioContext this way. Kevin
