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 <peter.mayd...@linaro.org> > > wrote: > > > On 27 November 2014 at 12:33, Michael S. Tsirkin <m...@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 <we...@cn.fujitsu.com> > > >>> Cc: Stefano Stabellini <stefano.stabell...@eu.citrix.com> > > >>> Cc: qemu-sta...@nongnu.org > > >>> Signed-off-by: Jason Wang <jasow...@redhat.com> > > >> > > >> Reviewed-by: Michael S. Tsirkin <m...@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... > > > > ...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.
