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 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.
