From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:43447) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cADdM-0005E4-NN for qemu-devel@nongnu.org; Fri, 25 Nov 2016 05:21:33 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cADdL-0001DD-RZ for qemu-devel@nongnu.org; Fri, 25 Nov 2016 05:21:32 -0500 Date: Fri, 25 Nov 2016 11:21:21 +0100 From: Kevin Wolf Message-ID: <20161125102121.GB4584@noname.redhat.com> References: <20161125100629.88589-1-haoqf@linux.vnet.ibm.com> <20161125100629.88589-2-haoqf@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161125100629.88589-2-haoqf@linux.vnet.ibm.com> Subject: Re: [Qemu-devel] [PATCH for-2.8 v1 1/1] block/vmdk: Fix the endian problem of buf_len List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: QingFeng Hao Cc: qemu-devel@nongnu.org, qemu-block@nongnu.org, cornelia.huck@de.ibm.com, borntraeger@de.ibm.com, famz@redhat.com, qemu-stable@nongnu.org [ Cc: Fam, qemu-stable ] Am 25.11.2016 um 11:06 hat QingFeng Hao geschrieben: > The problem was triggered by qemu-iotests case 055. It failed when it > was comparing the compressed vmdk image with original test.img. > > The cause is that buf_len in vmdk_write_extent wasn't converted to > little-endian before it was stored to disk. But later vmdk_read_extent > read it and converted it from little-endian to cpu endian. > If the cpu is big-endian like s390, the problem will happen and > the data length read by vmdk_read_extent will become invalid! > The fix is to add the conversion in vmdk_write_extent. > > Signed-off-by: QingFeng Hao > Signed-off-by: Jing Liu Sounds like something that should still be fixed for 2.8 and in the stable branches. > diff --git a/block/vmdk.c b/block/vmdk.c > index a11c27a..bf6667f 100644 > --- a/block/vmdk.c > +++ b/block/vmdk.c > @@ -1355,7 +1355,7 @@ static int vmdk_write_extent(VmdkExtent *extent, int64_t cluster_offset, > } > > data->lba = offset >> BDRV_SECTOR_BITS; > - data->size = buf_len; > + data->size = cpu_to_le32(buf_len); At least data->lba needs to be fixed, too, both here and in vmdk_read_extent(). Host endianness in an image file is always wrong. Maybe we should audit the whole driver for endianness problems. Kevin