From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:35890)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <ppandit@redhat.com>) id 1aJzP0-0006vC-3t
	for qemu-devel@nongnu.org; Fri, 15 Jan 2016 03:06:34 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <ppandit@redhat.com>) id 1aJzOz-0001Y5-88
	for qemu-devel@nongnu.org; Fri, 15 Jan 2016 03:06:34 -0500
Date: Fri, 15 Jan 2016 13:36:18 +0530 (IST)
From: P J P <ppandit@redhat.com>
In-Reply-To: <CAPokK=reMoLQ_CF_LgtmezkFZyUrSB3Oh_gB9kKZ=0Ztspq5Ag@mail.gmail.com>
Message-ID: <alpine.LFD.2.20.1601151327570.363@wniryva>
References: <1452764448-17953-1-git-send-email-mst@redhat.com>
	<CAFEAcA8yjfMdRtYsmdR=vbSmm0=6wdiFff2oUzYxwoT=CMbxyA@mail.gmail.com>
	<CAPokK=reMoLQ_CF_LgtmezkFZyUrSB3Oh_gB9kKZ=0Ztspq5Ag@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Subject: Re: [Qemu-devel] [Qemu-arm] [PATCH] cadence_gem: fix buffer overflow
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Peter Crosthwaite <crosthwaitepeter@gmail.com>
Cc: Peter Maydell <peter.maydell@linaro.org>, "Michael S. Tsirkin" <mst@redhat.com>, Jason Wang <jasowang@redhat.com>, QEMU Developers <qemu-devel@nongnu.org>, Alistair Francis <alistair.francis@xilinx.com>, qemu-arm <qemu-arm@nongnu.org>, =?GB2312?B?wfXB7g==?= <liuling-it@360.cn>

+-- On Thu, 14 Jan 2016, Peter Crosthwaite wrote --+
| I guess QEMU needs the whole packet before handing off to the net layer and 
| the assumption is that the packet is always within 2048. The easiest 
| solution is to realloc the buffer as it goes with the increasing sizes.

  Yes, I was considering increasing buffer size with view of the jumbo 
packets. In gem_transmit(), 'tx_desc_get_length' returns length masked by 
DESC_1_LENGTH(=0x1FFF=8191) bytes. But thought dynamic allocation might lead 
to excessive buffer allocation, not sure how constrained the Xilinx platform 
is for memory.

--
 - P J P
47AF CE69 3A90 54AA 9045 1053 DD13 3D32 FE5B 041F