From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:53613) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XvZ8u-0001ML-Fo for qemu-devel@nongnu.org; Mon, 01 Dec 2014 17:08:33 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XvZ8m-0004x4-Ku for qemu-devel@nongnu.org; Mon, 01 Dec 2014 17:08:28 -0500 Date: Mon, 1 Dec 2014 15:32:27 -0500 From: Konrad Rzeszutek Wilk Message-ID: <20141201203227.GA22021@laptop.dumpdata.com> References: <201411271531.sARFVwme008002@aserz7021.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [2.2 PATCH V2 for-4.5] virtio-net: fix unmap leak List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefano Stabellini Cc: Peter Maydell , Jason Wang , qemu-stable , QEMU-devel On Thu, Nov 27, 2014 at 05:46:28PM +0000, Stefano Stabellini wrote: > On Thu, 27 Nov 2014, Konrad Rzeszutek Wilk wrote: > > On Nov 27, 2014 10:26 AM, Stefano Stabellini wrote: > > > > > > On Thu, 27 Nov 2014, Konrad Rzeszutek Wilk wrote:=20 > > > > On Nov 27, 2014 9:58 AM, Stefano Stabellini wrote:=20 > > > > >=20 > > > > > On Thu, 27 Nov 2014, Konrad Rzeszutek Wilk wrote:=20 > > > > > > On Nov 27, 2014 7:46 AM, Stefano Stabellini wrote:=20 > > > > > > >=20 > > > > > > > Konrad, I think we should have this fix in 4.5: without it=20 > > > > > > > vif=3D[ 'model=3Dvirtio-net' ] crashes QEMU.=20 > > > > > > >=20 > > > > > >=20 > > > > > > Is it an regression?=20 > > > > >=20 > > > > > Good question: I was trying to investigate that.=20 > > > > >=20 > > > > > virtio-net is currently *not* documented in the xl interface:=20 > > > > >=20 > > > > >=20 > > > > > ### model=20 > > > > >=20 > > > > > This keyword is valid for HVM guest devices with `type=3Dioemu`= only.=20 > > > > >=20 > > > > > Specifies the type device to emulated for this guest. Valid val= ues=20 > > > > > are:=20 > > > > >=20 > > > > > =A0 * `rtl8139` (default) -- Realtek RTL8139=20 > > > > > =A0 * `e1000` -- Intel E1000=20 > > > > > =A0 * in principle any device supported by your device model=20 > > > > >=20 > > > > >=20 > > > > > The last working version of virtio-net on Xen is QEMU v1.4.0. T= hat means=20 > > > > > that the bug affects Xen 4.4 too (but it should work in Xen 4.3= ).=20 > > > >=20 > > > > Not a regression compared to 4.4 but it has been for two releases= .=20 > > > > > > That is true. On the plus side, virtio-net has never been properly=20 > > > documented as working in the first place.=20 > > > > > > > > > > So if nobody noticed it for two releases will they notice it if i= t not fixed in this release either? And can it be fixed in the next one?=20 > > > > > > We can fix the crash even in this release by backporting this rathe= r=20 > > > simple patch. However the patch would just avoid the crash: virtio-= net=20 > > > would still be not working once the guest is booted. I haven't figu= red=20 > > > out the cause of that problem yet.=20 > > > > >=20 > > Perhaps then the hack^H^Hfix is to return an error if user is using v= irtio-net then? > >=20 > > And then in later releases make it work right. >=20 > Sorry, I take it back: the fix is enough to get virtio-net working, I > had a configuration error that was confusing my test results. >=20 > Given that the fix is very simple, I think we should backport it to Xen= 4.5 > and Xen 4.4. OK. >>From 4.5 perspective: Release-Acked-by: Konrad Rzeszutek Wilk >=20 >=20 > > > > > > > On Thu, 27 Nov 2014, Peter Maydell wrote:=20 > > > > > > > > On 27 November 2014 at 12:33, Michael S. Tsirkin wrote:=20 > > > > > > > > > On Thu, Nov 27, 2014 at 06:04:03PM +0800, Jason Wang wr= ote:=20 > > > > > > > > >> virtio_net_handle_ctrl() and other functions that proc= ess control vq=20 > > > > > > > > >> request call iov_discard_front() which will shorten th= e iov. This will=20 > > > > > > > > >> lead unmapping in virtqueue_push() leaks mapping.=20 > > > > > > > > >>=20 > > > > > > > > >> Fixes this by keeping the original iov untouched and u= sing a temp variable=20 > > > > > > > > >> in those functions.=20 > > > > > > > > >>=20 > > > > > > > > >> Cc: Wen Congyang =20 > > > > > > > > >> Cc: Stefano Stabellini =20 > > > > > > > > >> Cc: qemu-stable@nongnu.org=20 > > > > > > > > >> Signed-off-by: Jason Wang =20 > > > > > > > > >=20 > > > > > > > > > Reviewed-by: Michael S. Tsirkin =20 > > > > > > > > >=20 > > > > > > > > > Peter, can you pick this up or do you want a pull reque= st?=20 > > > > > > > >=20 > > > > > > > > I can pick it up. I was waiting a bit to check that every= body=20 > > > > > > > > was happy that this is the correct way to fix the bug and= the=20 > > > > > > > > patch is ok...=20 > > > > > >=20 > > > >