From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:52926) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xu0c0-00065l-En for qemu-devel@nongnu.org; Thu, 27 Nov 2014 10:04:08 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Xu0bw-0002EO-JV for qemu-devel@nongnu.org; Thu, 27 Nov 2014 10:04:04 -0500 Date: Thu, 27 Nov 2014 17:03:39 +0200 From: "Michael S. Tsirkin" Message-ID: <20141127150339.GA26331@redhat.com> References: <1417082643-23907-1-git-send-email-jasowang@redhat.com> <20141127123341.GC13476@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [Qemu-devel] [2.2 PATCH V2] virtio-net: fix unmap leak List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefano Stabellini Cc: Peter Maydell , Fam Zheng , Stefan Hajnoczi , Jason Wang , QEMU Developers , qemu-stable , Anthony Liguori On Thu, Nov 27, 2014 at 02:54:47PM +0000, Stefano Stabellini wrote: > On Thu, 27 Nov 2014, Peter Maydell wrote: > > On 27 November 2014 at 12:42, Peter Maydell wrote: > > > On 27 November 2014 at 12:33, Michael S. Tsirkin 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 > > >>> Cc: Stefano Stabellini > > >>> Cc: qemu-stable@nongnu.org > > >>> Signed-off-by: Jason Wang > > >> > > >> Reviewed-by: Michael S. Tsirkin > > >> > > >> 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... > > > > ...but discussing this with Stefan H on IRC we realised that the same > > issue also (at least potentially) affects virtio-blk, which suggests > > that we should fix this by making the core virtio code cope with > > backends which modify the sglists. > > I think that a similar patch could be produced against > hw/block/virtio-blk.c:virtio_blk_handle_request Hmm, this is a data path operation. Adding malloc/free calls there will slow things down measureably. > Alternatively my series would help by introducing virtqueue_unmap_sg and > moving it out of virtqueue_fill. We could call virtqueue_unmap_sg from > the drivers (instead of calling it from virtqueue_push) and that would > solve the issue.