search for: rx_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 >>&...

...... >>>>> >>>>> 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 >>&...

...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...

...;> 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...

...;> 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...

...@@ 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_EVENT] must be accessed with event_lock held. */ struct mutex event_lock; + bool event_run; struct virtio_vsock_event event_list[8]; u32 guest_cid; @@ -94,6 +97,10 @@ static void virtio_tra...

...@@ 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_EVENT] must be accessed with event_lock held. */ struct mutex event_lock; + bool event_run; struct virtio_vsock_event event_list[8]; u32 guest_cid; @@ -94,6 +97,10 @@ static void virtio_tra...

...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->...

...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->...

...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 pr...

...... > > > > > > > > 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 > >...

...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); > }

...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); > }

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

...tio_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 a...

...ontainer_of(work, struct virtio_vsock, loopback_work); - LIST_HEAD(pkts); - - spin_lock_bh(&vsock->loopback_list_lock); - list_splice_init(&vsock->loopback_list, &pkts); - spin_unlock_bh(&vsock->loopback_list_lock); - - mutex_lock(&vsock->rx_lock); - - if (!vsock->rx_run) - goto out; - - while (!list_empty(&pkts)) { - struct virtio_vsock_pkt *pkt; - - pkt = list_first_entry(&pkts, struct virtio_vsock_pkt, list); - list_del_init(&pkt->list); - - virtio_transport_recv_pkt(pkt); - } -out: - mutex_unlock(&vsock->rx_lock); -} - static int vir...

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