public inbox for kvm@vger.kernel.org
 help / color / mirror / Atom feed
From: Mark McLoughlin <markmc@redhat.com>
To: avi <avi@qumranet.com>
Cc: kvm <kvm@vger.kernel.org>
Subject: Re: [ kvm-Bugs-2009439 ] data corruption with virtio-blk
Date: Thu, 03 Jul 2008 09:03:01 +0100	[thread overview]
Message-ID: <1215072181.4028.3.camel@muff> (raw)
In-Reply-To: <E1KEHjR-00037c-1k@h45xhf1.ch3.sourceforge.com>

Hi Avi,

On Thu, 2008-07-03 at 05:51 +0000, SourceForge.net wrote:
> Bugs item #2009439, was opened at 2008-07-03 11:21
> Message generated for change (Tracker Item Submitted) made by Item Submitter
> You can respond by visiting: 
> https://sourceforge.net/tracker/?func=detail&atid=893831&aid=2009439&group_id=180599
...
> Summary: data corruption with virtio-blk
> 
> Initial Comment:
> kvm-userspace : kvm-70-138-g163308a
> 
> With a kernel from linux-2.6.git (v2.6.26-rc8-89-ge1441b9), data
> corruption is seen on block devices when exported through virtio. Once
> a block device is mounted and unmounted in a guest, the kernel   is
> not able to find a filesystem in the block device when  being
> remounted. This is seen from the host as well.

I think the below fixes the data corrupter, but I'm still tracking down
another issue where the guest is hanging waiting for I/O to complete
with the latest virtio-blk backend.

Cheers,
Mark.

Subject: [PATCH] kvm: qemu: Fix virtio-blk data corrupter

Fix a typo in "avoid fragmented virtio-blk transfers by copying"
which causes data corruption.

See also:

  https://sf.net/tracker/?func=detail&atid=893831&aid=2009439&group_id=180599

Signed-off-by: Mark McLoughlin <markmc@redhat.com>
---
 qemu/hw/virtio-blk.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/qemu/hw/virtio-blk.c b/qemu/hw/virtio-blk.c
index c88f477..88dc086 100644
--- a/qemu/hw/virtio-blk.c
+++ b/qemu/hw/virtio-blk.c
@@ -186,7 +186,7 @@ static void virtio_blk_handle_output(VirtIODevice *vdev, VirtQueue *vq)
 	    for (i = 1; i < req->elem.out_num; i++) {
 		size_t len;
 
-		len = MIN(req->elem.in_sg[i].iov_len,
+		len = MIN(req->elem.out_sg[i].iov_len,
 			  req->size - offset);
 		memcpy(req->buffer + offset,
 		       req->elem.out_sg[i].iov_base,
-- 
1.5.5.1





  reply	other threads:[~2008-07-03 11:59 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-07-03  5:51 [ kvm-Bugs-2009439 ] data corruption with virtio-blk SourceForge.net
2008-07-03  8:03 ` Mark McLoughlin [this message]
2008-07-03 14:06   ` Avi Kivity
2008-07-03 14:58   ` Javier Guerra
2008-07-05 10:29     ` Mark McLoughlin
2008-07-07 16:10       ` Javier Guerra
  -- strict thread matches above, loose matches on Subject: below --
2008-07-07  8:32 SourceForge.net
2008-07-10 14:32 SourceForge.net

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1215072181.4028.3.camel@muff \
    --to=markmc@redhat.com \
    --cc=avi@qumranet.com \
    --cc=kvm@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox