similar to: [PATCH] 9p/trans_virtio: reset virtio device on remove

On device hot-unplug, 9p/virtio currently will kfree channel while it might still be in use. Of course, it might stay used forever, so it's an extremely ugly hack, but it seems better than use-after-free that we have now. Signed-off-by: Michael S. Tsirkin <mst at redhat.com> --- net/9p/trans_virtio.c | 25 +++++++++++++++++++++---- 1 file changed, 21 insertions(+), 4 deletions(-)

On device hot-unplug, 9p/virtio currently will kfree channel while it might still be in use. Of course, it might stay used forever, so it's an extremely ugly hack, but it seems better than use-after-free that we have now. Signed-off-by: Michael S. Tsirkin <mst at redhat.com> --- net/9p/trans_virtio.c | 25 +++++++++++++++++++++---- 1 file changed, 21 insertions(+), 4 deletions(-)

On Thu, Mar 12, 2015 at 11:54:10AM +1030, Rusty Russell wrote: > "Michael S. Tsirkin" <mst at redhat.com> writes: > > On device hot-unplug, 9p/virtio currently will kfree channel while > > it might still be in use. > > > > Of course, it might stay used forever, so it's an extremely ugly hack, > > but it seems better than use-after-free that we

On Thu, Mar 12, 2015 at 11:54:10AM +1030, Rusty Russell wrote: > "Michael S. Tsirkin" <mst at redhat.com> writes: > > On device hot-unplug, 9p/virtio currently will kfree channel while > > it might still be in use. > > > > Of course, it might stay used forever, so it's an extremely ugly hack, > > but it seems better than use-after-free that we

"Michael S. Tsirkin" <mst at redhat.com> writes: > On device hot-unplug, 9p/virtio currently will kfree channel while > it might still be in use. > > Of course, it might stay used forever, so it's an extremely ugly hack, > but it seems better than use-after-free that we have now. > > Signed-off-by: Michael S. Tsirkin <mst at redhat.com> I'll

"Michael S. Tsirkin" <mst at redhat.com> writes: > On device hot-unplug, 9p/virtio currently will kfree channel while > it might still be in use. > > Of course, it might stay used forever, so it's an extremely ugly hack, > but it seems better than use-after-free that we have now. > > Signed-off-by: Michael S. Tsirkin <mst at redhat.com> I'll

On Wed, Dec 04, 2013 at 08:43:18PM +0000, Richard Yao wrote: > The 9p-virtio transport does zero copy on things larger than 1024 bytes > in size. It accomplishes this by returning the physical addresses of > pages to the virtio-pci device. At present, the translation is usually a > bit shift. > > However, that approach produces an invalid page address when we > read/write to

On 12/06/2013 06:14 AM, Will Deacon wrote: > On Wed, Dec 04, 2013 at 08:43:18PM +0000, Richard Yao wrote: >> The 9p-virtio transport does zero copy on things larger than 1024 bytes >> in size. It accomplishes this by returning the physical addresses of >> pages to the virtio-pci device. At present, the translation is usually a >> bit shift. >> >> However,

On 12/06/2013 06:14 AM, Will Deacon wrote: > On Wed, Dec 04, 2013 at 08:43:18PM +0000, Richard Yao wrote: >> The 9p-virtio transport does zero copy on things larger than 1024 bytes >> in size. It accomplishes this by returning the physical addresses of >> pages to the virtio-pci device. At present, the translation is usually a >> bit shift. >> >> However,

The 9p-virtio transport does zero copy on things larger than 1024 bytes in size. It accomplishes this by returning the physical addresses of pages to the virtio-pci device. At present, the translation is usually a bit shift. However, that approach produces an invalid page address when we read/write to vmalloc buffers, such as those used for Linux kernle modules. This causes QEMU to die printing:

The 9p-virtio transport does zero copy on things larger than 1024 bytes in size. It accomplishes this by returning the physical addresses of pages to the virtio-pci device. At present, the translation is usually a bit shift. However, that approach produces an invalid page address when we read/write to vmalloc buffers, such as those used for Linux kernle modules. This causes QEMU to die printing:

Currently if VIRTIO_RING_F_INDIRECT_DESC is enabled we will use indirect descriptors even if we have plenty of space in the ring. This means that we take a performance hit at all times due to the overhead of creating indirect descriptors. Instead, use it only after we're below a configurable offset. Signed-off-by: Sasha Levin <levinsasha928 at gmail.com> --- drivers/block/virtio_blk.c

Currently if VIRTIO_RING_F_INDIRECT_DESC is enabled we will use indirect descriptors even if we have plenty of space in the ring. This means that we take a performance hit at all times due to the overhead of creating indirect descriptors. Instead, use it only after we're below a configurable offset. Signed-off-by: Sasha Levin <levinsasha928 at gmail.com> --- drivers/block/virtio_blk.c

Currently if VIRTIO_RING_F_INDIRECT_DESC is enabled we will use indirect descriptors even if we have plenty of space in the ring. This means that we take a performance hit at all times due to the overhead of creating indirect descriptors. Instead, use it only after we're below a configurable offset. Signed-off-by: Sasha Levin <levinsasha928 at gmail.com> --- drivers/block/virtio_blk.c

Currently if VIRTIO_RING_F_INDIRECT_DESC is enabled we will use indirect descriptors even if we have plenty of space in the ring. This means that we take a performance hit at all times due to the overhead of creating indirect descriptors. Instead, use it only after we're below a configurable offset. Signed-off-by: Sasha Levin <levinsasha928 at gmail.com> --- drivers/block/virtio_blk.c

Currently if VIRTIO_RING_F_INDIRECT_DESC is enabled we will use indirect descriptors even if we have plenty of space in the ring. This means that we take a performance hit at all times due to the overhead of creating indirect descriptors. Instead, use it only after we're below a configurable offset. Signed-off-by: Sasha Levin <levinsasha928 at gmail.com> --- drivers/block/virtio_blk.c

Currently if VIRTIO_RING_F_INDIRECT_DESC is enabled we will use indirect descriptors even if we have plenty of space in the ring. This means that we take a performance hit at all times due to the overhead of creating indirect descriptors. Instead, use it only after we're below a configurable offset. Signed-off-by: Sasha Levin <levinsasha928 at gmail.com> --- drivers/block/virtio_blk.c

This replaces find_vq/del_vq with find_vqs/del_vqs virtio operations, and updates all drivers. This is needed for MSI support, because MSI needs to know the total number of vectors upfront. Signed-off-by: Michael S. Tsirkin <mst at redhat.com> --- drivers/block/virtio_blk.c | 6 ++-- drivers/char/hw_random/virtio-rng.c | 6 ++-- drivers/char/virtio_console.c | 26

This replaces find_vq/del_vq with find_vqs/del_vqs virtio operations, and updates all drivers. This is needed for MSI support, because MSI needs to know the total number of vectors upfront. Signed-off-by: Michael S. Tsirkin <mst at redhat.com> --- drivers/block/virtio_blk.c | 6 ++-- drivers/char/hw_random/virtio-rng.c | 6 ++-- drivers/char/virtio_console.c | 26

This replaces find_vq/del_vq with find_vqs/del_vqs virtio operations, and updates all drivers. This is needed for MSI support, because MSI needs to know the total number of vectors upfront. Signed-off-by: Michael S. Tsirkin <mst at redhat.com> --- Untested - Rusty could you pls take a look before I go ahead and rebase the rest on top of this? drivers/block/virtio_blk.c | 12