[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [Bug 1191606] Re: qemu crashes with iscsi initiator (li
From: |
Laszlo Ersek |
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 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130513 Thunderbird/17.0.6 |
On 06/20/13 17:31, ronnie sahlberg wrote:
> On Thu, Jun 20, 2013 at 7:47 AM, Laszlo Ersek <address@hidden> 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
[Prev in Thread] |
Current Thread |
[Next in Thread] |