search for: virtio_transport_send_pkt

...;>>> Some questions after a quick glance: >>>>>> >>>>>> 1) It looks to me that the work could be queued from the path of >>>>>> vsock_transport_cancel_pkt() . Is that synchronized here? >>>>>> >>>>> Both virtio_transport_send_pkt() and vsock_transport_cancel_pkt() can >>>>> queue work from the upper layer (socket). >>>>> >>>>> Setting the_virtio_vsock to NULL, should synchronize, but after a careful look >>>>> a rare issue could happen: >>>>> we are...

...;>>> Some questions after a quick glance: >>>>>> >>>>>> 1) It looks to me that the work could be queued from the path of >>>>>> vsock_transport_cancel_pkt() . Is that synchronized here? >>>>>> >>>>> Both virtio_transport_send_pkt() and vsock_transport_cancel_pkt() can >>>>> queue work from the upper layer (socket). >>>>> >>>>> Setting the_virtio_vsock to NULL, should synchronize, but after a careful look >>>>> a rare issue could happen: >>>>> we are...

...ck glance: >>>>>>>> >>>>>>>> 1) It looks to me that the work could be queued from the path of >>>>>>>> vsock_transport_cancel_pkt() . Is that synchronized here? >>>>>>>> >>>>>>> Both virtio_transport_send_pkt() and vsock_transport_cancel_pkt() can >>>>>>> queue work from the upper layer (socket). >>>>>>> >>>>>>> Setting the_virtio_vsock to NULL, should synchronize, but after a careful look >>>>>>> a rare issue could happ...

...; + virtio_vsock_flush_works(vsock); >>>> Some questions after a quick glance: >>>> >>>> 1) It looks to me that the work could be queued from the path of >>>> vsock_transport_cancel_pkt() . Is that synchronized here? >>>> >>> Both virtio_transport_send_pkt() and vsock_transport_cancel_pkt() can >>> queue work from the upper layer (socket). >>> >>> Setting the_virtio_vsock to NULL, should synchronize, but after a careful look >>> a rare issue could happen: >>> we are setting the_virtio_vsock to NULL at the...

...; + virtio_vsock_flush_works(vsock); >>>> Some questions after a quick glance: >>>> >>>> 1) It looks to me that the work could be queued from the path of >>>> vsock_transport_cancel_pkt() . Is that synchronized here? >>>> >>> Both virtio_transport_send_pkt() and vsock_transport_cancel_pkt() can >>> queue work from the upper layer (socket). >>> >>> Setting the_virtio_vsock to NULL, should synchronize, but after a careful look >>> a rare issue could happen: >>> we are setting the_virtio_vsock to NULL at the...

...er free. >>> + */ >>> + virtio_vsock_flush_works(vsock); >> >> Some questions after a quick glance: >> >> 1) It looks to me that the work could be queued from the path of >> vsock_transport_cancel_pkt() . Is that synchronized here? >> > Both virtio_transport_send_pkt() and vsock_transport_cancel_pkt() can > queue work from the upper layer (socket). > > Setting the_virtio_vsock to NULL, should synchronize, but after a careful look > a rare issue could happen: > we are setting the_virtio_vsock to NULL at the start of .remove() and we > are freei...

...er free. >>> + */ >>> + virtio_vsock_flush_works(vsock); >> >> Some questions after a quick glance: >> >> 1) It looks to me that the work could be queued from the path of >> vsock_transport_cancel_pkt() . Is that synchronized here? >> > Both virtio_transport_send_pkt() and vsock_transport_cancel_pkt() can > queue work from the upper layer (socket). > > Setting the_virtio_vsock to NULL, should synchronize, but after a careful look > a rare issue could happen: > we are setting the_virtio_vsock to NULL at the start of .remove() and we > are freei...

...> > > > > > > > > > > > > > 1) It looks to me that the work could be queued from the path of > > > > > > > vsock_transport_cancel_pkt() . Is that synchronized here? > > > > > > > > > > > > > Both virtio_transport_send_pkt() and vsock_transport_cancel_pkt() can > > > > > > queue work from the upper layer (socket). > > > > > > > > > > > > Setting the_virtio_vsock to NULL, should synchronize, but after a careful look > > > > > > a rare issue could...

On 2019/5/28 ??6:56, Stefano Garzarella wrote: > We flush all pending works before to call vdev->config->reset(vdev), > but other works can be queued before the vdev->config->del_vqs(vdev), > so we add another flush after it, to avoid use after free. > > Suggested-by: Michael S. Tsirkin <mst at redhat.com> > Signed-off-by: Stefano Garzarella <sgarzare at

On 2019/5/28 ??6:56, Stefano Garzarella wrote: > We flush all pending works before to call vdev->config->reset(vdev), > but other works can be queued before the vdev->config->del_vqs(vdev), > so we add another flush after it, to avoid use after free. > > Suggested-by: Michael S. Tsirkin <mst at redhat.com> > Signed-off-by: Stefano Garzarella <sgarzare at

..._transport.c | 36 ++++++++++++++++++++++++++++++++++++ 1 file changed, 36 insertions(+) diff --git a/net/vmw_vsock/virtio_transport.c b/net/vmw_vsock/virtio_transport.c index 936d7ee..f88b6ed 100644 --- a/net/vmw_vsock/virtio_transport.c +++ b/net/vmw_vsock/virtio_transport.c @@ -170,6 +170,41 @@ virtio_transport_send_pkt(struct virtio_vsock_pkt *pkt) return len; } +static int +virtio_transport_cancel_pkt(struct vsock_sock *vsk) +{ + struct virtio_vsock *vsock; + struct virtio_vsock_pkt *pkt, *n; + int cnt = 0; + LIST_HEAD(freeme); + + vsock = virtio_vsock_get(); + if (!vsock) { + return -ENODEV; + } + + if (p...

...ck object to avoid use after free. > > + */ > > + virtio_vsock_flush_works(vsock); > > > Some questions after a quick glance: > > 1) It looks to me that the work could be queued from the path of > vsock_transport_cancel_pkt() . Is that synchronized here? > Both virtio_transport_send_pkt() and vsock_transport_cancel_pkt() can queue work from the upper layer (socket). Setting the_virtio_vsock to NULL, should synchronize, but after a careful look a rare issue could happen: we are setting the_virtio_vsock to NULL at the start of .remove() and we are freeing the object pointed by it a...

...t; > > Some questions after a quick glance: > > > > > > > > > > 1) It looks to me that the work could be queued from the path of > > > > > vsock_transport_cancel_pkt() . Is that synchronized here? > > > > > > > > > Both virtio_transport_send_pkt() and vsock_transport_cancel_pkt() can > > > > queue work from the upper layer (socket). > > > > > > > > Setting the_virtio_vsock to NULL, should synchronize, but after a careful look > > > > a rare issue could happen: > > > > we are sett...

...DR_CID_ANY; > + goto out_rcu; > + } > > - return vsock->guest_cid; > + ret = vsock->guest_cid; > +out_rcu: > + rcu_read_unlock(); > + return ret; > } > > static void virtio_transport_loopback_work(struct work_struct *work) > @@ -197,14 +200,18 @@ virtio_transport_send_pkt(struct virtio_vsock_pkt *pkt) > struct virtio_vsock *vsock; > int len = pkt->len; > > - vsock = virtio_vsock_get(); > + rcu_read_lock(); > + vsock = rcu_dereference(the_virtio_vsock); > if (!vsock) { > virtio_transport_free_pkt(pkt); > - return -ENODEV...

...DR_CID_ANY; > + goto out_rcu; > + } > > - return vsock->guest_cid; > + ret = vsock->guest_cid; > +out_rcu: > + rcu_read_unlock(); > + return ret; > } > > static void virtio_transport_loopback_work(struct work_struct *work) > @@ -197,14 +200,18 @@ virtio_transport_send_pkt(struct virtio_vsock_pkt *pkt) > struct virtio_vsock *vsock; > int len = pkt->len; > > - vsock = virtio_vsock_get(); > + rcu_read_lock(); > + vsock = rcu_dereference(the_virtio_vsock); > if (!vsock) { > virtio_transport_free_pkt(pkt); > - return -ENODEV...

...irtio_vsock_flush_works(vsock); > > > > > > Some questions after a quick glance: > > > > > > 1) It looks to me that the work could be queued from the path of > > > vsock_transport_cancel_pkt() . Is that synchronized here? > > > > > Both virtio_transport_send_pkt() and vsock_transport_cancel_pkt() can > > queue work from the upper layer (socket). > > > > Setting the_virtio_vsock to NULL, should synchronize, but after a careful look > > a rare issue could happen: > > we are setting the_virtio_vsock to NULL at the start of .remo...

...;> - return vsock->guest_cid; >>> + ret = vsock->guest_cid; >>> +out_rcu: >>> + rcu_read_unlock(); >>> + return ret; >>> } >>> static void virtio_transport_loopback_work(struct work_struct *work) >>> @@ -197,14 +200,18 @@ virtio_transport_send_pkt(struct virtio_vsock_pkt *pkt) >>> struct virtio_vsock *vsock; >>> int len = pkt->len; >>> - vsock = virtio_vsock_get(); >>> + rcu_read_lock(); >>> + vsock = rcu_dereference(the_virtio_vsock); >>> if (!vsock) { >>> vi...

...;> - return vsock->guest_cid; >>> + ret = vsock->guest_cid; >>> +out_rcu: >>> + rcu_read_unlock(); >>> + return ret; >>> } >>> static void virtio_transport_loopback_work(struct work_struct *work) >>> @@ -197,14 +200,18 @@ virtio_transport_send_pkt(struct virtio_vsock_pkt *pkt) >>> struct virtio_vsock *vsock; >>> int len = pkt->len; >>> - vsock = virtio_vsock_get(); >>> + rcu_read_lock(); >>> + vsock = rcu_dereference(the_virtio_vsock); >>> if (!vsock) { >>> vi...

...nsport.c | 42 ++++++++++++++++++++++++++++++++++++++++ 1 file changed, 42 insertions(+) diff --git a/net/vmw_vsock/virtio_transport.c b/net/vmw_vsock/virtio_transport.c index 936d7ee..a5f3833 100644 --- a/net/vmw_vsock/virtio_transport.c +++ b/net/vmw_vsock/virtio_transport.c @@ -170,6 +170,47 @@ virtio_transport_send_pkt(struct virtio_vsock_pkt *pkt) return len; } +static int +virtio_transport_cancel_pkt(struct vsock_sock *vsk) +{ + struct virtio_vsock *vsock; + struct virtio_vsock_pkt *pkt, *n; + int cnt = 0; + LIST_HEAD(freeme); + + vsock = virtio_vsock_get(); + if (!vsock) { + return -ENODEV; + } + + spin_...

...rcu_dereference(the_virtio_vsock); + if (!vsock) { + ret = VMADDR_CID_ANY; + goto out_rcu; + } - return vsock->guest_cid; + ret = vsock->guest_cid; +out_rcu: + rcu_read_unlock(); + return ret; } static void virtio_transport_loopback_work(struct work_struct *work) @@ -197,14 +200,18 @@ virtio_transport_send_pkt(struct virtio_vsock_pkt *pkt) struct virtio_vsock *vsock; int len = pkt->len; - vsock = virtio_vsock_get(); + rcu_read_lock(); + vsock = rcu_dereference(the_virtio_vsock); if (!vsock) { virtio_transport_free_pkt(pkt); - return -ENODEV; + len = -ENODEV; + goto out_rcu; } - if (l...