From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Peter Maydell <peter.maydell@linaro.org>,
Jason Wang <jasowang@redhat.com>,
qemu-stable <qemu-stable@nongnu.org>,
QEMU-devel <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] [2.2 PATCH V2 for-4.5] virtio-net: fix unmap leak
Date: Mon, 1 Dec 2014 15:32:27 -0500 [thread overview]
Message-ID: <20141201203227.GA22021@laptop.dumpdata.com> (raw)
In-Reply-To: <alpine.DEB.2.02.1411271740120.14135@kaball.uk.xensource.com>
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 <stefano.stabellini@eu.citrix.com> wrote:
> > >
> > > On Thu, 27 Nov 2014, Konrad Rzeszutek Wilk wrote:
> > > > On Nov 27, 2014 9:58 AM, Stefano Stabellini <stefano.stabellini@eu.citrix.com> wrote:
> > > > >
> > > > > On Thu, 27 Nov 2014, Konrad Rzeszutek Wilk wrote:
> > > > > > On Nov 27, 2014 7:46 AM, Stefano Stabellini <stefano.stabellini@eu.citrix.com> wrote:
> > > > > > >
> > > > > > > Konrad, I think we should have this fix in 4.5: without it
> > > > > > > vif=[ 'model=virtio-net' ] crashes QEMU.
> > > > > > >
> > > > > >
> > > > > > Is it an regression?
> > > > >
> > > > > Good question: I was trying to investigate that.
> > > > >
> > > > > virtio-net is currently *not* documented in the xl interface:
> > > > >
> > > > >
> > > > > ### model
> > > > >
> > > > > This keyword is valid for HVM guest devices with `type=ioemu` only.
> > > > >
> > > > > Specifies the type device to emulated for this guest. Valid values
> > > > > are:
> > > > >
> > > > > * `rtl8139` (default) -- Realtek RTL8139
> > > > > * `e1000` -- Intel E1000
> > > > > * in principle any device supported by your device model
> > > > >
> > > > >
> > > > > The last working version of virtio-net on Xen is QEMU v1.4.0. That means
> > > > > that the bug affects Xen 4.4 too (but it should work in Xen 4.3).
> > > >
> > > > Not a regression compared to 4.4 but it has been for two releases.
> > >
> > > That is true. On the plus side, virtio-net has never been properly
> > > documented as working in the first place.
> > >
> > >
> > > > So if nobody noticed it for two releases will they notice it if it not fixed in this release either? And can it be fixed in the next one?
> > >
> > > We can fix the crash even in this release by backporting this rather
> > > simple patch. However the patch would just avoid the crash: virtio-net
> > > would still be not working once the guest is booted. I haven't figured
> > > out the cause of that problem yet.
> > >
> >
> > Perhaps then the hack^H^Hfix is to return an error if user is using virtio-net then?
> >
> > And then in later releases make it work right.
>
> 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.
>
> 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 <konrad.wilk@oracle.com>
>
>
> > > > > > > On Thu, 27 Nov 2014, Peter Maydell wrote:
> > > > > > > > On 27 November 2014 at 12:33, Michael S. Tsirkin <mst@redhat.com> wrote:
> > > > > > > > > On Thu, Nov 27, 2014 at 06:04:03PM +0800, Jason Wang wrote:
> > > > > > > > >> virtio_net_handle_ctrl() and other functions that process control vq
> > > > > > > > >> request call iov_discard_front() which will shorten the iov. This will
> > > > > > > > >> lead unmapping in virtqueue_push() leaks mapping.
> > > > > > > > >>
> > > > > > > > >> Fixes this by keeping the original iov untouched and using a temp variable
> > > > > > > > >> in those functions.
> > > > > > > > >>
> > > > > > > > >> Cc: Wen Congyang <wency@cn.fujitsu.com>
> > > > > > > > >> Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > > > > > > > >> Cc: qemu-stable@nongnu.org
> > > > > > > > >> Signed-off-by: Jason Wang <jasowang@redhat.com>
> > > > > > > > >
> > > > > > > > > Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
> > > > > > > > >
> > > > > > > > > Peter, can you pick this up or do you want a pull request?
> > > > > > > >
> > > > > > > > I can pick it up. I was waiting a bit to check that everybody
> > > > > > > > was happy that this is the correct way to fix the bug and the
> > > > > > > > patch is ok...
> > > > > >
> > > >
next prev parent reply other threads:[~2014-12-01 22:08 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-27 15:31 [Qemu-devel] [2.2 PATCH V2 for-4.5] virtio-net: fix unmap leak Konrad Rzeszutek Wilk
2014-11-27 17:46 ` Stefano Stabellini
2014-12-01 20:32 ` Konrad Rzeszutek Wilk [this message]
-- strict thread matches above, loose matches on Subject: below --
2014-11-27 15:05 Konrad Rzeszutek Wilk
2014-11-27 15:26 ` Stefano Stabellini
2014-11-27 14:53 Konrad Rzeszutek Wilk
2014-11-27 14:58 ` Stefano Stabellini
2014-11-27 10:04 [Qemu-devel] [2.2 PATCH V2] " Jason Wang
2014-11-27 12:33 ` Michael S. Tsirkin
2014-11-27 12:42 ` Peter Maydell
2014-11-27 12:46 ` [Qemu-devel] [2.2 PATCH V2 for-4.5] " Stefano Stabellini
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20141201203227.GA22021@laptop.dumpdata.com \
--to=konrad.wilk@oracle.com \
--cc=jasowang@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=qemu-stable@nongnu.org \
--cc=stefano.stabellini@eu.citrix.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.