Displaying 20 results from an estimated 96 matches for "virtio_vsock_prob".
Did you mean:
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?
> > >
> > >...
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?
> > >
> > >...
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(&...
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(&...
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_...
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_...
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(&...
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(&...
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
> blo...
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 in...
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_l...
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 t...
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(...
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(&...