search for: virtio_vsock_probe

Displaying 20 results from an estimated 96 matches for "virtio_vsock_probe".

2019 May 15
2
[PATCH] vsock/virtio: Initialize core virtio vsock before registering the driver
...t; - ret = register_virtio_driver(&virtio_vsock_driver); > > > > > + ret = vsock_core_init(&virtio_transport.transport); > > > > > > > > Have you checked that all transport callbacks are safe even if another > > > > CPU calls them while virtio_vsock_probe() is executing on another CPU? > > > > > > > > > > I have the same doubt. > > > > > > What do you think to take the 'the_virtio_vsock_mutex' in the > > > virtio_vsock_init(), keeping the previous order? > > > > > > T...
2019 May 15
2
[PATCH] vsock/virtio: Initialize core virtio vsock before registering the driver
...t; - ret = register_virtio_driver(&virtio_vsock_driver); > > > > > + ret = vsock_core_init(&virtio_transport.transport); > > > > > > > > Have you checked that all transport callbacks are safe even if another > > > > CPU calls them while virtio_vsock_probe() is executing on another CPU? > > > > > > > > > > I have the same doubt. > > > > > > What do you think to take the 'the_virtio_vsock_mutex' in the > > > virtio_vsock_init(), keeping the previous order? > > > > > > T...
2019 Jul 03
3
[PATCH v2 1/3] vsock/virtio: use RCU to avoid use-after-free on the_virtio_vsock
...queue_work(virtio_vsock_workqueue, &vsock->rx_work); > } > > - return 0; > + ret = 0; > + > +out_rcu: > + rcu_read_unlock(); > + return ret; > } > > static void virtio_vsock_rx_fill(struct virtio_vsock *vsock) > @@ -590,8 +606,6 @@ static int virtio_vsock_probe(struct virtio_device *vdev) > vsock->rx_buf_max_nr = 0; > atomic_set(&vsock->queued_replies, 0); > > - vdev->priv = vsock; > - the_virtio_vsock = vsock; > mutex_init(&vsock->tx_lock); > mutex_init(&vsock->rx_lock); > mutex_init(&a...
2019 Jul 03
3
[PATCH v2 1/3] vsock/virtio: use RCU to avoid use-after-free on the_virtio_vsock
...queue_work(virtio_vsock_workqueue, &vsock->rx_work); > } > > - return 0; > + ret = 0; > + > +out_rcu: > + rcu_read_unlock(); > + return ret; > } > > static void virtio_vsock_rx_fill(struct virtio_vsock *vsock) > @@ -590,8 +606,6 @@ static int virtio_vsock_probe(struct virtio_device *vdev) > vsock->rx_buf_max_nr = 0; > atomic_set(&vsock->queued_replies, 0); > > - vdev->priv = vsock; > - the_virtio_vsock = vsock; > mutex_init(&vsock->tx_lock); > mutex_init(&vsock->rx_lock); > mutex_init(&a...
2019 May 02
2
[PATCH] vsock/virtio: Initialize core virtio vsock before registering the driver
...ock_workqueue) > > return -ENOMEM; > > > > - ret = register_virtio_driver(&virtio_vsock_driver); > > + ret = vsock_core_init(&virtio_transport.transport); > > Have you checked that all transport callbacks are safe even if another > CPU calls them while virtio_vsock_probe() is executing on another CPU? > I have the same doubt. What do you think to take the 'the_virtio_vsock_mutex' in the virtio_vsock_init(), keeping the previous order? This should prevent this issue because the virtio_vsock_probe() remains blocked in the mutex until the end of vsock_c...
2019 May 02
2
[PATCH] vsock/virtio: Initialize core virtio vsock before registering the driver
...ock_workqueue) > > return -ENOMEM; > > > > - ret = register_virtio_driver(&virtio_vsock_driver); > > + ret = vsock_core_init(&virtio_transport.transport); > > Have you checked that all transport callbacks are safe even if another > CPU calls them while virtio_vsock_probe() is executing on another CPU? > I have the same doubt. What do you think to take the 'the_virtio_vsock_mutex' in the virtio_vsock_init(), keeping the previous order? This should prevent this issue because the virtio_vsock_probe() remains blocked in the mutex until the end of vsock_c...
2019 Jul 04
2
[PATCH v2 1/3] vsock/virtio: use RCU to avoid use-after-free on the_virtio_vsock
...t;> } >>> - return 0; >>> + ret = 0; >>> + >>> +out_rcu: >>> + rcu_read_unlock(); >>> + return ret; >>> } >>> static void virtio_vsock_rx_fill(struct virtio_vsock *vsock) >>> @@ -590,8 +606,6 @@ static int virtio_vsock_probe(struct virtio_device *vdev) >>> vsock->rx_buf_max_nr = 0; >>> atomic_set(&vsock->queued_replies, 0); >>> - vdev->priv = vsock; >>> - the_virtio_vsock = vsock; >>> mutex_init(&vsock->tx_lock); >>> mutex_init(&a...
2019 Jul 04
2
[PATCH v2 1/3] vsock/virtio: use RCU to avoid use-after-free on the_virtio_vsock
...t;> } >>> - return 0; >>> + ret = 0; >>> + >>> +out_rcu: >>> + rcu_read_unlock(); >>> + return ret; >>> } >>> static void virtio_vsock_rx_fill(struct virtio_vsock *vsock) >>> @@ -590,8 +606,6 @@ static int virtio_vsock_probe(struct virtio_device *vdev) >>> vsock->rx_buf_max_nr = 0; >>> atomic_set(&vsock->queued_replies, 0); >>> - vdev->priv = vsock; >>> - the_virtio_vsock = vsock; >>> mutex_init(&vsock->tx_lock); >>> mutex_init(&a...
2019 May 16
0
[PATCH] vsock/virtio: Initialize core virtio vsock before registering the driver
...r_virtio_driver(&virtio_vsock_driver); > > > > > > + ret = vsock_core_init(&virtio_transport.transport); > > > > > > > > > > Have you checked that all transport callbacks are safe even if another > > > > > CPU calls them while virtio_vsock_probe() is executing on another CPU? > > > > > > > > > > > > > I have the same doubt. > > > > > > > > What do you think to take the 'the_virtio_vsock_mutex' in the > > > > virtio_vsock_init(), keeping the previous order? &...
2019 May 06
1
[PATCH] vsock/virtio: Initialize core virtio vsock before registering the driver
...urn -ENOMEM; > > > > > > - ret = register_virtio_driver(&virtio_vsock_driver); > > > + ret = vsock_core_init(&virtio_transport.transport); > > > > Have you checked that all transport callbacks are safe even if another > > CPU calls them while virtio_vsock_probe() is executing on another CPU? > > > > I have the same doubt. > > What do you think to take the 'the_virtio_vsock_mutex' in the > virtio_vsock_init(), keeping the previous order? > > This should prevent this issue because the virtio_vsock_probe() remains > bloc...
2019 Jul 05
0
[PATCH v3 1/3] vsock/virtio: use RCU to avoid use-after-free on the_virtio_vsock
...267,11 @@ virtio_transport_cancel_pkt(struct vsock_sock *vsk) queue_work(virtio_vsock_workqueue, &vsock->rx_work); } - return 0; + ret = 0; + +out_rcu: + rcu_read_unlock(); + return ret; } static void virtio_vsock_rx_fill(struct virtio_vsock *vsock) @@ -565,7 +581,8 @@ static int virtio_vsock_probe(struct virtio_device *vdev) return ret; /* Only one virtio-vsock device per guest is supported */ - if (the_virtio_vsock) { + if (rcu_dereference_protected(the_virtio_vsock, + lockdep_is_held(&the_virtio_vsock_mutex))) { ret = -EBUSY; goto out; } @@ -590,8 +607,6 @@ static int...
2019 Jul 03
0
[PATCH v2 1/3] vsock/virtio: use RCU to avoid use-after-free on the_virtio_vsock
..., &vsock->rx_work); > > } > > - return 0; > > + ret = 0; > > + > > +out_rcu: > > + rcu_read_unlock(); > > + return ret; > > } > > static void virtio_vsock_rx_fill(struct virtio_vsock *vsock) > > @@ -590,8 +606,6 @@ static int virtio_vsock_probe(struct virtio_device *vdev) > > vsock->rx_buf_max_nr = 0; > > atomic_set(&vsock->queued_replies, 0); > > - vdev->priv = vsock; > > - the_virtio_vsock = vsock; > > mutex_init(&vsock->tx_lock); > > mutex_init(&vsock->rx_lock);...
2019 Jul 05
4
[PATCH v3 0/3] vsock/virtio: several fixes in the .probe() and .remove()
...to call vdev->config->reset(vdev) to be sure that no one is accessing the device. - Patch 3 moves the works flush at the end of the .remove() to avoid use-after-free of 'vsock' object. v3: - Patch 1: use rcu_dereference_protected() to get the_virtio_vosck value in the virtio_vsock_probe() [Jason] v2: https://patchwork.kernel.org/cover/11022343/ v1: https://patchwork.kernel.org/cover/10964733/ Before this series the guest crashes in a few second. After this series the test runs (~12h) without issues. Tested on an SMP guest (-smp 4 -monitor tcp:127.0.0.1:1234,server,nowait) with...
2019 Jul 04
0
[PATCH v2 1/3] vsock/virtio: use RCU to avoid use-after-free on the_virtio_vsock
...; + ret = 0; > > > > + > > > > +out_rcu: > > > > + rcu_read_unlock(); > > > > + return ret; > > > > } > > > > static void virtio_vsock_rx_fill(struct virtio_vsock *vsock) > > > > @@ -590,8 +606,6 @@ static int virtio_vsock_probe(struct virtio_device *vdev) > > > > vsock->rx_buf_max_nr = 0; > > > > atomic_set(&vsock->queued_replies, 0); > > > > - vdev->priv = vsock; > > > > - the_virtio_vsock = vsock; > > > > mutex_init(&vsock->tx_lo...
2019 May 07
0
[PATCH] vsock/virtio: Initialize core virtio vsock before registering the driver
...t; > > > > - ret = register_virtio_driver(&virtio_vsock_driver); > > > > + ret = vsock_core_init(&virtio_transport.transport); > > > > > > Have you checked that all transport callbacks are safe even if another > > > CPU calls them while virtio_vsock_probe() is executing on another CPU? > > > > > > > I have the same doubt. > > > > What do you think to take the 'the_virtio_vsock_mutex' in the > > virtio_vsock_init(), keeping the previous order? > > > > This should prevent this issue because th...
2019 May 28
0
[PATCH 1/4] vsock/virtio: fix locking around 'the_virtio_vsock'
...io_vsock_get(void) { - return the_virtio_vsock; + struct virtio_vsock *vsock; + + mutex_lock(&the_virtio_vsock_mutex); + vsock = the_virtio_vsock; + mutex_unlock(&the_virtio_vsock_mutex); + + return vsock; } static u32 virtio_transport_get_local_cid(void) @@ -592,7 +598,6 @@ static int virtio_vsock_probe(struct virtio_device *vdev) atomic_set(&vsock->queued_replies, 0); vdev->priv = vsock; - the_virtio_vsock = vsock; mutex_init(&vsock->tx_lock); mutex_init(&vsock->rx_lock); mutex_init(&vsock->event_lock); @@ -614,6 +619,8 @@ static int virtio_vsock_probe(s...
2019 May 28
8
[PATCH 0/4] vsock/virtio: several fixes in the .probe() and .remove()
During the review of "[PATCH] vsock/virtio: Initialize core virtio vsock before registering the driver", Stefan pointed out some possible issues in the .probe() and .remove() callbacks of the virtio-vsock driver. This series tries to solve these issues: - Patch 1 postpones the 'the_virtio_vsock' assignment at the end of the .probe() to avoid that some sockets queue works when
2019 May 28
8
[PATCH 0/4] vsock/virtio: several fixes in the .probe() and .remove()
During the review of "[PATCH] vsock/virtio: Initialize core virtio vsock before registering the driver", Stefan pointed out some possible issues in the .probe() and .remove() callbacks of the virtio-vsock driver. This series tries to solve these issues: - Patch 1 postpones the 'the_virtio_vsock' assignment at the end of the .probe() to avoid that some sockets queue works when
2019 Jun 28
0
[PATCH v2 1/3] vsock/virtio: use RCU to avoid use-after-free on the_virtio_vsock
...267,11 @@ virtio_transport_cancel_pkt(struct vsock_sock *vsk) queue_work(virtio_vsock_workqueue, &vsock->rx_work); } - return 0; + ret = 0; + +out_rcu: + rcu_read_unlock(); + return ret; } static void virtio_vsock_rx_fill(struct virtio_vsock *vsock) @@ -590,8 +606,6 @@ static int virtio_vsock_probe(struct virtio_device *vdev) vsock->rx_buf_max_nr = 0; atomic_set(&vsock->queued_replies, 0); - vdev->priv = vsock; - the_virtio_vsock = vsock; mutex_init(&vsock->tx_lock); mutex_init(&vsock->rx_lock); mutex_init(&vsock->event_lock); @@ -613,6 +627,9 @@...
2019 May 29
2
[PATCH 3/4] vsock/virtio: fix flush of works during the .remove()
...nged, 17 insertions(+), 6 deletions(-) > > diff --git a/net/vmw_vsock/virtio_transport.c b/net/vmw_vsock/virtio_transport.c > index e694df10ab61..ad093ce96693 100644 > --- a/net/vmw_vsock/virtio_transport.c > +++ b/net/vmw_vsock/virtio_transport.c > @@ -660,6 +660,15 @@ static int virtio_vsock_probe(struct virtio_device *vdev) > return ret; > } > > +static void virtio_vsock_flush_works(struct virtio_vsock *vsock) > +{ > + flush_work(&vsock->loopback_work); > + flush_work(&vsock->rx_work); > + flush_work(&vsock->tx_work); > + flush_work(&a...