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 <address@hidden>
---
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.