blob: e211015fa3382e4c2b00acd35e671206b4a9a6cf (
plain) (
blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
|
<think>
Alright, let me try to figure this out. So, the user is reporting a bug in QEMU where using bdrv_read in a loop causes a coroutine re-entry issue. They provided some code snippets.
Looking at the code, `bdrv_co_io_em` is a coroutine function that calls either `bdrv_aio_readv` or `bdrv_aio_writev`, which are asynchronous I/O functions. These functions take a completion callback, `bdrv_co_io_em_complete`, which in turn uses `qemu_coroutine_enter` to resume the coroutine.
The problem arises when `bdrv_co_io_em_complete` is called before `qemu_coroutine_yield` is reached in `bdrv_co_io_em`. This leads to the coroutine being re-entered recursively, causing QEMU to fail with an error about recursive coroutine entry.
I remember that coroutines in QEMU must not be re-entered without proper yielding. So if the completion callback runs before yielding, it can cause this issue. It's more likely related to how I/O operations are handled in user-mode since block device reads and coroutines are part of the user-space implementation.
So, this seems like a bug in the coroutine handling within the block driver layer, which operates at the user mode level.
</think>
The bug report is about a coroutine re-entry issue when using `bdrv_read` in a loop. The problem occurs because the completion callback (`bdrv_co_io_em_complete`) can be called before yielding the coroutine, leading to recursive entry. This relates to how coroutines and I/O operations are managed in user-space.
user
|