search for: tx_run

...... >>>>> >>>>> free(vsock); >>>>> } >>>>> >>>>> Could there be a better approach? >>>>> >>>>> >>>>>> 2) If we decide to flush after dev_vqs(), is tx_run/rx_run/event_run still >>>>>> needed? It looks to me we've already done except that we need flush rx_work >>>>>> in the end since send_pkt_work can requeue rx_work. >>>>> The main reason of tx_run/rx_run/event_run is to prevent that a worker &g...

...... >>>>> >>>>> free(vsock); >>>>> } >>>>> >>>>> Could there be a better approach? >>>>> >>>>> >>>>>> 2) If we decide to flush after dev_vqs(), is tx_run/rx_run/event_run still >>>>>> needed? It looks to me we've already done except that we need flush rx_work >>>>>> in the end since send_pkt_work can requeue rx_work. >>>>> The main reason of tx_run/rx_run/event_run is to prevent that a worker &g...

...gt;> free(vsock); >>>>>>> } >>>>>>> >>>>>>> Could there be a better approach? >>>>>>> >>>>>>> >>>>>>>> 2) If we decide to flush after dev_vqs(), is tx_run/rx_run/event_run still >>>>>>>> needed? It looks to me we've already done except that we need flush rx_work >>>>>>>> in the end since send_pkt_work can requeue rx_work. >>>>>>> The main reason of tx_run/rx_run/event_run is to...

...vmw_vsock/virtio_transport.c b/net/vmw_vsock/virtio_transport.c index 7ad510ec12e0..1b44ec6f3f6c 100644 --- a/net/vmw_vsock/virtio_transport.c +++ b/net/vmw_vsock/virtio_transport.c @@ -38,6 +38,7 @@ struct virtio_vsock { * must be accessed with tx_lock held. */ struct mutex tx_lock; + bool tx_run; struct work_struct send_pkt_work; spinlock_t send_pkt_list_lock; @@ -53,6 +54,7 @@ struct virtio_vsock { * must be accessed with rx_lock held. */ struct mutex rx_lock; + bool rx_run; int rx_buf_nr; int rx_buf_max_nr; @@ -60,6 +62,7 @@ struct virtio_vsock { * vqs[VSOCK_VQ_EVE...

...vmw_vsock/virtio_transport.c b/net/vmw_vsock/virtio_transport.c index 3eaec60aa64f..4dbdce7746bd 100644 --- a/net/vmw_vsock/virtio_transport.c +++ b/net/vmw_vsock/virtio_transport.c @@ -38,6 +38,7 @@ struct virtio_vsock { * must be accessed with tx_lock held. */ struct mutex tx_lock; + bool tx_run; struct work_struct send_pkt_work; spinlock_t send_pkt_list_lock; @@ -53,6 +54,7 @@ struct virtio_vsock { * must be accessed with rx_lock held. */ struct mutex rx_lock; + bool rx_run; int rx_buf_nr; int rx_buf_max_nr; @@ -60,6 +62,7 @@ struct virtio_vsock { * vqs[VSOCK_VQ_EVE...

...>>> synchronize_rcu(); >>> >>> ... >>> >>> free(vsock); >>> } >>> >>> Could there be a better approach? >>> >>> >>>> 2) If we decide to flush after dev_vqs(), is tx_run/rx_run/event_run still >>>> needed? It looks to me we've already done except that we need flush rx_work >>>> in the end since send_pkt_work can requeue rx_work. >>> The main reason of tx_run/rx_run/event_run is to prevent that a worker >>> function is r...

...>>> synchronize_rcu(); >>> >>> ... >>> >>> free(vsock); >>> } >>> >>> Could there be a better approach? >>> >>> >>>> 2) If we decide to flush after dev_vqs(), is tx_run/rx_run/event_run still >>>> needed? It looks to me we've already done except that we need flush rx_work >>>> in the end since send_pkt_work can requeue rx_work. >>> The main reason of tx_run/rx_run/event_run is to prevent that a worker >>> function is r...

...free(vsock); > > > > > > } > > > > > > > > > > > > Could there be a better approach? > > > > > > > > > > > > > > > > > > > 2) If we decide to flush after dev_vqs(), is tx_run/rx_run/event_run still > > > > > > > needed? It looks to me we've already done except that we need flush rx_work > > > > > > > in the end since send_pkt_work can requeue rx_work. > > > > > > The main reason of tx_run/rx_run/event_run i...

..._vsock_remove() > { > rcu_assign_pointer(the_virtio_vsock_mutex, NULL); > synchronize_rcu(); > > ... > > free(vsock); > } > > Could there be a better approach? > > >> 2) If we decide to flush after dev_vqs(), is tx_run/rx_run/event_run still >> needed? It looks to me we've already done except that we need flush rx_work >> in the end since send_pkt_work can requeue rx_work. > The main reason of tx_run/rx_run/event_run is to prevent that a worker > function is running while we are calling conf...

..._vsock_remove() > { > rcu_assign_pointer(the_virtio_vsock_mutex, NULL); > synchronize_rcu(); > > ... > > free(vsock); > } > > Could there be a better approach? > > >> 2) If we decide to flush after dev_vqs(), is tx_run/rx_run/event_run still >> needed? It looks to me we've already done except that we need flush rx_work >> in the end since send_pkt_work can requeue rx_work. > The main reason of tx_run/rx_run/event_run is to prevent that a worker > function is running while we are calling conf...

...vsock 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? 2) If we decide to flush after dev_vqs(), is tx_run/rx_run/event_run still needed? It looks to me we've already done except that we need flush rx_work in the end since send_pkt_work can requeue rx_work. Thanks > + > kfree(vsock); > mutex_unlock(&the_virtio_vsock_mutex); > }

...vsock 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? 2) If we decide to flush after dev_vqs(), is tx_run/rx_run/event_run still needed? It looks to me we've already done except that we need flush rx_work in the end since send_pkt_work can requeue rx_work. Thanks > + > kfree(vsock); > mutex_unlock(&the_virtio_vsock_mutex); > }

...; > ... > > > > > > > > free(vsock); > > > > } > > > > > > > > Could there be a better approach? > > > > > > > > > > > > > 2) If we decide to flush after dev_vqs(), is tx_run/rx_run/event_run still > > > > > needed? It looks to me we've already done except that we need flush rx_work > > > > > in the end since send_pkt_work can requeue rx_work. > > > > The main reason of tx_run/rx_run/event_run is to prevent that a worker &gt...

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 adds RCU critical sections to avoid use-after-free of 'the_virtio_vsock' pointer. - Patch 2 stops workers before to

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 adds RCU critical sections to avoid use-after-free of 'the_virtio_vsock' pointer. - Patch 2 stops workers before to

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 adds RCU critical sections to avoid use-after-free of 'the_virtio_vsock' pointer. - Patch 2 stops workers before to

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

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

..._mutex); ... rcu_read_unlock(); } virtio_vsock_remove() { rcu_assign_pointer(the_virtio_vsock_mutex, NULL); synchronize_rcu(); ... free(vsock); } Could there be a better approach? > 2) If we decide to flush after dev_vqs(), is tx_run/rx_run/event_run still > needed? It looks to me we've already done except that we need flush rx_work > in the end since send_pkt_work can requeue rx_work. The main reason of tx_run/rx_run/event_run is to prevent that a worker function is running while we are calling config->reset()....

...the_virtio_vsock_mutex, NULL); > > synchronize_rcu(); > > > > ... > > > > free(vsock); > > } > > > > Could there be a better approach? > > > > > > > 2) If we decide to flush after dev_vqs(), is tx_run/rx_run/event_run still > > > needed? It looks to me we've already done except that we need flush rx_work > > > in the end since send_pkt_work can requeue rx_work. > > The main reason of tx_run/rx_run/event_run is to prevent that a worker > > function is running whi...