qemu-devel
[Top][All Lists]
Advanced

[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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]