* Christoph Hellwig <h...@lst.de> [2011-08-22 10:37]:
> On Mon, Aug 22, 2011 at 10:29:11AM -0500, Ryan Harper wrote:
> > (gdb) frame 0
> > #0 0x00000000004200c1 in bdrv_acct_done (bs=0x12310b0, cookie=0x1c68810)
> > at /root/git/qemu/block_int.h:239 239 bs->nr_bytes[cookie->type] +=
> > cookie->bytes;
> > (gdb) p *cookie
> > $3 = {bytes = 72057589759737855, start_time_ns = 72057589759737855, type =
> > 16777215}
>
> So it is indeed corrupted. I'll try to figure out how that could have
> happened.
So, I believe this is how it's happening.
we start accounting on a write which is turned into a multiwrite via
virtio_blk_handle_write() which calls virtio_submit_multiwrite().
Then when the multiwrite completes, we invoke virtio_blk_rw_complete()
on each part of the multiwrite. None of these requests have had their
acct structure initialized since there was just *one* initial write.
We could do a bdrv_acct_start() on each req, but that would break the
concept of hiding the additional writes under the initial request.
So ensuring that the acct field is initialed when the request is
allocated will fix the issue.
With this patch, I don't see the crash anymore.
Signed-off-by: Ryan Harper <ry...@us.ibm.com>
diff --git a/hw/virtio-blk.c b/hw/virtio-blk.c
index 2660d1d..e746917 100644
--- a/hw/virtio-blk.c
+++ b/hw/virtio-blk.c
@@ -123,6 +123,7 @@ static VirtIOBlockReq *virtio_blk_alloc_request(VirtIOBlock
*s)
req->dev = s;
req->qiov.size = 0;
req->next = NULL;
+ memset(&req->acct, 0, sizeof(BlockAcctCookie));
return req;
}
--
Ryan Harper
Software Engineer; Linux Technology Center
IBM Corp., Austin, Tx
ry...@us.ibm.com
