search for: vq_callbacks

...(the_virtio_vsock, NULL); >> >> This is still suspicious, can we access the_virtio_vsock through vdev->priv? >> If yes, we may still get use-after-free since it was not protected by RCU. > We will free the object only after calling the del_vqs(), so we are sure > that the vq_callbacks ended and will no longer be invoked. > So, IIUC it shouldn't happen. Yes, but any dereference that is not done in vq_callbacks will be very dangerous in the future. Thanks > >> Another more interesting question, I believe we will do singleton for >> virtio_vsock structur...

...(the_virtio_vsock, NULL); >> >> This is still suspicious, can we access the_virtio_vsock through vdev->priv? >> If yes, we may still get use-after-free since it was not protected by RCU. > We will free the object only after calling the del_vqs(), so we are sure > that the vq_callbacks ended and will no longer be invoked. > So, IIUC it shouldn't happen. Yes, but any dereference that is not done in vq_callbacks will be very dangerous in the future. Thanks > >> Another more interesting question, I believe we will do singleton for >> virtio_vsock structur...

On Thu, Apr 16, 2020 at 09:56:40AM +0200, Eugenio P??rez wrote: > As updated in ("2a2d1382fe9d virtio: Add improved queue allocation API") > > Signed-off-by: Eugenio P??rez <eperezma at redhat.com> Pls add motivation for these changes. > --- > tools/virtio/virtio_test.c | 7 +++---- > 1 file changed, 3 insertions(+), 4 deletions(-) > > diff --git

...; > > > > > This is still suspicious, can we access the_virtio_vsock through vdev->priv? > > > If yes, we may still get use-after-free since it was not protected by RCU. > > We will free the object only after calling the del_vqs(), so we are sure > > that the vq_callbacks ended and will no longer be invoked. > > So, IIUC it shouldn't happen. > > > Yes, but any dereference that is not done in vq_callbacks will be very > dangerous in the future. Right. Do you think make sense to continue with this series in order to fix the hot-unplug issue,...

On 2019/6/28 ??8:36, Stefano Garzarella wrote: > Some callbacks used by the upper layers can run while we are in the > .remove(). A potential use-after-free can happen, because we free > the_virtio_vsock without knowing if the callbacks are over or not. > > To solve this issue we move the assignment of the_virtio_vsock at the > end of .probe(), when we finished all the

On 2019/6/28 ??8:36, Stefano Garzarella wrote: > Some callbacks used by the upper layers can run while we are in the > .remove(). A potential use-after-free can happen, because we free > the_virtio_vsock without knowing if the callbacks are over or not. > > To solve this issue we move the assignment of the_virtio_vsock at the > end of .probe(), when we finished all the

Commit db932ced55cf ("virtio: add context flag to find vqs") added a new 'context' flag to vring_new_virtqueue(), but the corresponding API in tools/virtio/ is not updated causing build errors due to conflicting declarations. Bring code in tools/virtio in sync with that in kernel. I have used 'false' for the value of the new boolean 'context' flag as that seems

Commit db932ced55cf ("virtio: add context flag to find vqs") added a new 'context' flag to vring_new_virtqueue(), but the corresponding API in tools/virtio/ is not updated causing build errors due to conflicting declarations. Bring code in tools/virtio in sync with that in kernel. I have used 'false' for the value of the new boolean 'context' flag as that seems

...assign_pointer(the_virtio_vsock, NULL); > > > This is still suspicious, can we access the_virtio_vsock through vdev->priv? > If yes, we may still get use-after-free since it was not protected by RCU. We will free the object only after calling the del_vqs(), so we are sure that the vq_callbacks ended and will no longer be invoked. So, IIUC it shouldn't happen. > > Another more interesting question, I believe we will do singleton for > virtio_vsock structure. Then what's the point of using vdev->priv to access > the_virtio_vsock? It looks to me we can it brings ext...

Hello, Here are two patches. One implements a virtio-serial device in qemu and the other is the driver for a guest kernel. While working on a vmchannel interface that is needed for communication between guest userspace and host userspace, I saw that most of the interface can be abstracted out as a "serial" device with "ports". Some requirements for a vmchannel are listed at

Hello, Here are two patches. One implements a virtio-serial device in qemu and the other is the driver for a guest kernel. While working on a vmchannel interface that is needed for communication between guest userspace and host userspace, I saw that most of the interface can be abstracted out as a "serial" device with "ports". Some requirements for a vmchannel are listed at

...ret = virtserial_add_port(port_nr); + if (!ret) + virtserial.config->nr_active_ports++; + } + kfree(virtserconf); +} + +static int virtserial_probe(struct virtio_device *vdev) +{ + struct virtqueue *vqs[2]; + const char *vq_names[] = { "input", "output" }; + vq_callback_t *vq_callbacks[] = { rx_intr, tx_intr }; + u32 i, map; + int ret, map_i; + u32 max_nr_ports; + + vdev->config->get(vdev, offsetof(struct virtio_serial_config, + max_nr_ports), + &max_nr_ports, + sizeof(max_nr_ports)); + virtserial.config = kmalloc(sizeof(struct virtio_serial_config) +...

...ret = virtserial_add_port(port_nr); + if (!ret) + virtserial.config->nr_active_ports++; + } + kfree(virtserconf); +} + +static int virtserial_probe(struct virtio_device *vdev) +{ + struct virtqueue *vqs[2]; + const char *vq_names[] = { "input", "output" }; + vq_callback_t *vq_callbacks[] = { rx_intr, tx_intr }; + u32 i, map; + int ret, map_i; + u32 max_nr_ports; + + vdev->config->get(vdev, offsetof(struct virtio_serial_config, + max_nr_ports), + &max_nr_ports, + sizeof(max_nr_ports)); + virtserial.config = kmalloc(sizeof(struct virtio_serial_config) +...

Hello, This is a new iteration of the patches that implement virtio-serial. Changes include: * Adding support for port hot-add * Creating ports at specific ids that can be bound to specific apps / usage * Cleanups This code still doesn't get rid of the support for assigning names to ports but it just has to be ripped out. Comments welcome. Thanks, Amit.

Hello, This is a new iteration of the patches that implement virtio-serial. Changes include: * Adding support for port hot-add * Creating ports at specific ids that can be bound to specific apps / usage * Cleanups This code still doesn't get rid of the support for assigning names to ports but it just has to be ripped out. Comments welcome. Thanks, Amit.

Here's a patchset to update tools/virtio with changes in 3.8, as well as the proposed API extension. Useful to see whether the extra level of indirection adds measureable overhead. I will upstream at least patch 1 soon. Michael S. Tsirkin (2): tools/virtio: fix build for 3.8 tools/virtio: update for the new virtio API drivers/vhost/test.c | 4 +++- tools/virtio/Makefile

Here's a patchset to update tools/virtio with changes in 3.8, as well as the proposed API extension. Useful to see whether the extra level of indirection adds measureable overhead. I will upstream at least patch 1 soon. Michael S. Tsirkin (2): tools/virtio: fix build for 3.8 tools/virtio: update for the new virtio API drivers/vhost/test.c | 4 +++- tools/virtio/Makefile

Currently a host kick error is silently ignored and not reflected in the virtqueue of a particular virtio device. Changing the notify API for guest->host notification seems to be one prerequisite in order to be able to handle such errors in the context where the kick is triggered. This patch changes the notify API. The notify function must return a negative int return value in case the host

Recent changes to drivers/virtio broke compilation for the tests in tools/virtio. The following patches are build fixes for those changes, as well as a fix for a typo that would have never built. The changes were tested on my amd64 system against 3.14-rc2. Joel Stanley (3): tools/virtio: update internal copies of headers tools/virtio: fix missing kmemleak_ignore symbol tools/virtio: add a

Recent changes to drivers/virtio broke compilation for the tests in tools/virtio. The following patches are build fixes for those changes, as well as a fix for a typo that would have never built. The changes were tested on my amd64 system against 3.14-rc2. Joel Stanley (3): tools/virtio: update internal copies of headers tools/virtio: fix missing kmemleak_ignore symbol tools/virtio: add a