On Fri, Apr 15, 2016 at 01:31:59PM +0200, Paolo Bonzini wrote: > @@ -255,6 +257,8 @@ aio_ctx_finalize(GSource *source) > } > #endif > > + qemu_bh_delete(ctx->schedule_bh);
Please include an assertion that the scheduled coroutines list is empty.
> +
> qemu_lockcnt_lock(&ctx->list_lock);
> assert(!qemu_lockcnt_count(&ctx->list_lock));
> while (ctx->first_bh) {
> @@ -335,6 +339,28 @@ static void event_notifier_dummy_cb(EventNotifier *e)
> {
> }
>
> +static void schedule_bh_cb(void *opaque)
> +{
> + AioContext *ctx = opaque;
> + QSLIST_HEAD(, Coroutine) straight, reversed;
> +
> + QSLIST_MOVE_ATOMIC(&reversed, &ctx->scheduled_coroutines);
> + QSLIST_INIT(&straight);
> +
> + while (!QSLIST_EMPTY(&reversed)) {
> + Coroutine *co = QSLIST_FIRST(&reversed);
> + QSLIST_REMOVE_HEAD(&reversed, co_scheduled_next);
> + QSLIST_INSERT_HEAD(&straight, co, co_scheduled_next);
> + }
> +
> + while (!QSLIST_EMPTY(&straight)) {
> + Coroutine *co = QSLIST_FIRST(&straight);
> + QSLIST_REMOVE_HEAD(&straight, co_scheduled_next);
> + trace_aio_schedule_bh_cb(ctx, co);
> + qemu_coroutine_enter(co, NULL);
> + }
> +}
This construct brings to mind the use-after-free case when a scheduled
coroutine terminates before it is entered by this loop:
There are two scheduled Coroutines: A and B. During
qemu_coroutine_enter(A) we enter B. B then terminates by returning from
its main function. Once A yields or terminates we still try to enter
the freed B coroutine.
Unfortunately I don't think we have good debugging or an assertion for
this bug. I'm sure it will occur at some point... Please document
that the coroutine must not be entered by anyone else while
aio_co_schedule() is active.
signature.asc
Description: PGP signature
