From: Laszlo Ersek <lersek@redhat.com>
To: ronnie sahlberg <ronniesahlberg@gmail.com>
Cc: Bug 1191606 <1191606@bugs.launchpad.net>,
qemu-devel <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] [Bug 1191606] Re: qemu crashes with iscsi initiator (libiscsi) when using virtio
Date: Thu, 20 Jun 2013 17:47:28 +0200 [thread overview]
Message-ID: <51C32410.8070904@redhat.com> (raw)
In-Reply-To: <CAN05THT87GOE=E5+=45G8yJqgobFPLUYVX+_AyWdh5i-L6q0EA@mail.gmail.com>
On 06/20/13 17:31, ronnie sahlberg wrote:
> On Thu, Jun 20, 2013 at 7:47 AM, Laszlo Ersek <lersek@redhat.com> wrote:
>> First I don't understand how access_len can only be "1". But, in any
>> case, if the "req->elem.in_sg[0].iov_base" pointer is stored in
>> little-endian order, and the kernel (or iscsi_scsi_command_async()?) for
>> whatever reason misinterprets "hdr.dxferp" to point at an actual receive
>> buffer (instead of an iovec array), that would be consistent with the
>> symptoms:
>
> Ah, that makes sense.
>
> block.iscsi.c (https://github.com/qemu/qemu/blob/master/block/iscsi.c)
> does assume that ioh->dxferp is a pointer to the buffer and that there
> is no scatter gather.
> See lines 745-749.
How could I miss that? :) I stopped looking at the
iscsi_scsi_command_async() call on line 734. Sheesh.
> I did not know that ioctl() could take a scatter/gather list.
>
>
> I cant test now but if I understand right then
> lines 745-749 should be replaced with something that does
>
> * check ioh->iovec_count IF if it zero then there is no scatter gather
> and ioh->dxferp points to a buffer, so just do what we do today.
> * IF iovec_count is > 0 then dxferp is NOT a pointer to a buffer but
> a pointer to an array of iovec then
> traverse the iovec array and add these as buffers to the task just
> like we do for readv. For example similar to the loop to add the
> iovecs in lines 449-453
Seems correct to me.
>
>
> I will try this tonight.
Thanks!
Laszlo
next prev parent reply other threads:[~2013-06-20 15:45 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-06-16 23:48 [Qemu-devel] [Bug 1191606] [NEW] qemu crashes with iscsi initiator (libiscsi) when using virtio Klaus Hochlehnert
2013-06-16 23:54 ` [Qemu-devel] [Bug 1191606] " Klaus Hochlehnert
2013-06-17 13:02 ` [Qemu-devel] [Bug 1191606] [NEW] " Stefan Hajnoczi
2013-06-17 17:37 ` [Qemu-devel] [Bug 1191606] " Klaus Hochlehnert
2013-06-18 9:38 ` Stefan Hajnoczi
2013-06-18 12:26 ` Laszlo Ersek
2013-06-18 14:37 ` Stefan Hajnoczi
2013-06-18 18:01 ` Klaus Hochlehnert
2013-06-18 19:36 ` Laszlo Ersek
2013-06-19 4:34 ` ronnie sahlberg
2013-06-19 8:54 ` Stefan Hajnoczi
2013-06-19 9:17 ` Laszlo Ersek
2013-06-20 13:33 ` ronnie sahlberg
2013-06-20 14:47 ` Laszlo Ersek
2013-06-20 15:31 ` ronnie sahlberg
2013-06-20 15:47 ` Laszlo Ersek [this message]
2013-06-24 19:46 ` Laszlo Ersek (Red Hat)
2013-09-25 6:25 ` Klaus Hochlehnert
2013-09-25 7:30 ` Paolo Bonzini
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=51C32410.8070904@redhat.com \
--to=lersek@redhat.com \
--cc=1191606@bugs.launchpad.net \
--cc=qemu-devel@nongnu.org \
--cc=ronniesahlberg@gmail.com \
/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;
as well as URLs for NNTP newsgroup(s).