similar to: [PATCH] 9p/trans_virtio.c: Fix broken zero-copy on vmalloc() buffers

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,

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

Some virtio device drivers (9p) need to translate high virtual addresses to physical addresses, which are inserted into the virtqueue for processing by userspace. This patch exports the kmap_to_page symbol, so that the affected drivers can be compiled as modules. Signed-off-by: Will Deacon <will.deacon at arm.com> --- mm/highmem.c | 1 + 1 files changed, 1 insertions(+), 0 deletions(-)

Some virtio device drivers (9p) need to translate high virtual addresses to physical addresses, which are inserted into the virtqueue for processing by userspace. This patch exports the kmap_to_page symbol, so that the affected drivers can be compiled as modules. Signed-off-by: Will Deacon <will.deacon at arm.com> --- mm/highmem.c | 1 + 1 files changed, 1 insertions(+), 0 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 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

Will Deacon <will.deacon at arm.com> writes: > When using a virtio transport, the 9p net device allocates pages to back > the descriptors inserted into the virtqueue. These allocations may be > performed from atomic context (under the channel lock) and can therefore > return high mappings which aren't suitable for virt_to_phys. I had not appreciated that subtlety about

Will Deacon <will.deacon at arm.com> writes: > When using a virtio transport, the 9p net device allocates pages to back > the descriptors inserted into the virtqueue. These allocations may be > performed from atomic context (under the channel lock) and can therefore > return high mappings which aren't suitable for virt_to_phys. I had not appreciated that subtlety about

On Tue, Feb 24, 2015 at 11:56:50PM +0100, Olivier Mauras wrote: > > > On Tue, 2015-02-24 at 16:05 -0500, Laine Stump wrote: > > On 02/24/2015 03:37 PM, Olivier Mauras wrote: > > >> Hello, > > >> > > >> I've been trying to boot a VM with the rootfs being a 9P share from > > >> the host. The VM OS is centos 7. > > >>

"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 device shutdown/removal, virtio drivers need to trigger a reset on the device; if this is neglected, the virtio core will complain about non-zero device status. This patch resets the status when the 9p virtio driver is removed from the system by calling vdev->config->reset on the virtio_device to send a reset to the host virtio device. Signed-off-by: Pierre Morel <pmorel at

On device shutdown/removal, virtio drivers need to trigger a reset on the device; if this is neglected, the virtio core will complain about non-zero device status. This patch resets the status when the 9p virtio driver is removed from the system by calling vdev->config->reset on the virtio_device to send a reset to the host virtio device. Signed-off-by: Pierre Morel <pmorel at

On 02/24/2015 03:37 PM, Olivier Mauras wrote: >> Hello, >> >> I've been trying to boot a VM with the rootfs being a 9P share from >> the host. The VM OS is centos 7. >> The OS boots but no services can work and it appears that the >> authentication system is broken. >> >> Now the funny thing is that booting the same OS on the same 9P share

Hello, I've been trying to boot a VM with the rootfs being a 9P share from the host. The VM OS is centos 7. The OS boots but no services can work and it appears that the authentication system is broken. Now the funny thing is that booting the same OS on the same 9P share manually with Qemu works as expected with a fully functionnal OS... So I'm wondering what could libvirt do that render

Hi Eric, Just cleaning up patches for 2.6.25 merge, and noticed that net/9p/trans_virtio.c doesn't have a remove function. This will crash when removing the module (console doesn't have one because it can't really be removed). I'll push the latest queue in a couple of hours: the most important thing is that it's now drivers' responsibility to call (the new!)

Hi Eric, Just cleaning up patches for 2.6.25 merge, and noticed that net/9p/trans_virtio.c doesn't have a remove function. This will crash when removing the module (console doesn't have one because it can't really be removed). I'll push the latest queue in a couple of hours: the most important thing is that it's now drivers' responsibility to call (the new!)