Il 02/07/2014 13:33, ChenLiang ha scritto:
On 2014/7/2 18:16, Paolo Bonzini wrote:
Il 02/07/2014 11:46, Gonglei (Arei) ha scritto:
Hi, Paolo. We have tested your above patch, and it works well for us.
I'm still not sure where the fix is. I jotted the patch quickly, but I'd
rather understand it better before submitting it. Here is it again:
--- a/dma-helpers.c
+++ b/dma-helpers.c
@@ -181,15 +181,15 @@ static void dma_aio_cancel(BlockDriverAIOCB *acb)
trace_dma_aio_cancel(dbs);
+ dbs->in_cancel = true;
if (dbs->acb) {
BlockDriverAIOCB *acb = dbs->acb;
dbs->acb = NULL;
- dbs->in_cancel = true;
bdrv_aio_cancel(acb);
- dbs->in_cancel = false;
}
dbs->common.cb = NULL;
dma_complete(dbs, 0);
+ qemu_aio_release(dbs);
}
Hmm, dbs->in_cancel will be true always. Although this will avoid freeing dbs
by dma_comlete.
But it maybe a mistake.
This was on purpose; I'm doing the free myself in dma_aio_cancel, so I
wanted to avoid the qemu_aio_release from dma_complete. This was in
case of a recursive call to dma_complete. But I don't see how that
recursive call could happen outside the "if (dbs->acb)"; and inside the
"if" the protection is there already.
Can you gather the backtraces for _both_ calls to qemu_aio_release,
rather than just the second?
With what guest are you encountering the bug?
Paolo
