search for: flush_workers

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

On 2019/5/29 ??6:58, Stefano Garzarella wrote: > On Wed, May 29, 2019 at 11:22:40AM +0800, Jason Wang wrote: >> 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

On 2019/5/29 ??6:58, Stefano Garzarella wrote: > On Wed, May 29, 2019 at 11:22:40AM +0800, Jason Wang wrote: >> 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

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 redhat.com> --- net/vmw_vsock/virtio_transport.c | 23

This patch moves the flush of works after vdev->config->del_vqs(vdev), because we need to be sure that no workers run before to free the 'vsock' object. Since we stopped the workers using the [tx|rx|event]_run flags, we are sure no one is accessing the device while we are calling vdev->config->reset(vdev), so we can safely move the workers' flush. Before the

This patch moves the flush of works after vdev->config->del_vqs(vdev), because we need to be sure that no workers run before to free the 'vsock' object. Since we stopped the workers using the [tx|rx|event]_run flags, we are sure no one is accessing the device while we are calling vdev->config->reset(vdev), so we can safely move the workers' flush. Before the

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

On Thu, May 30, 2019 at 05:46:18PM +0800, Jason Wang wrote: > > On 2019/5/29 ??6:58, Stefano Garzarella wrote: > > On Wed, May 29, 2019 at 11:22:40AM +0800, Jason Wang wrote: > > > 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

On Wed, May 29, 2019 at 11:22:40AM +0800, Jason Wang wrote: > > 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

On 2019/5/30 ??6:10, Stefano Garzarella wrote: > On Thu, May 30, 2019 at 05:46:18PM +0800, Jason Wang wrote: >> On 2019/5/29 ??6:58, Stefano Garzarella wrote: >>> On Wed, May 29, 2019 at 11:22:40AM +0800, Jason Wang wrote: >>>> On 2019/5/28 ??6:56, Stefano Garzarella wrote: >>>>> We flush all pending works before to call vdev->config->reset(vdev),

On 2019/5/30 ??6:10, Stefano Garzarella wrote: > On Thu, May 30, 2019 at 05:46:18PM +0800, Jason Wang wrote: >> On 2019/5/29 ??6:58, Stefano Garzarella wrote: >>> On Wed, May 29, 2019 at 11:22:40AM +0800, Jason Wang wrote: >>>> On 2019/5/28 ??6:56, Stefano Garzarella wrote: >>>>> We flush all pending works before to call vdev->config->reset(vdev),

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

On Tue, Sep 03, 2019 at 04:45:41PM -0400, Lyude Paul wrote: > When reprobing an MST topology during resume, we have to account for the > fact that while we were suspended it's possible that mstbs may have been > removed from any ports in the topology. Since iterating downwards in the > topology requires that we hold &mgr->lock, destroying MSTBs from this > context would

On Sun, 5 Oct 2014 19:07:13 +0300 "Michael S. Tsirkin" <mst at redhat.com> wrote: > Now that virtio core ensures config changes don't arrive during probing, > drop config_enable flag in virtio net. > On removal, flush is now sufficient to guarantee that no change work is > queued. > > This help simplify the driver, and will allow setting DRIVER_OK earlier

On Sun, 5 Oct 2014 19:07:13 +0300 "Michael S. Tsirkin" <mst at redhat.com> wrote: > Now that virtio core ensures config changes don't arrive during probing, > drop config_enable flag in virtio net. > On removal, flush is now sufficient to guarantee that no change work is > queued. > > This help simplify the driver, and will allow setting DRIVER_OK earlier

On Wed, Sep 25, 2019 at 04:08:22PM -0400, Lyude Paul wrote: > On Wed, 2019-09-25 at 14:16 -0400, Sean Paul wrote: > > On Tue, Sep 03, 2019 at 04:45:41PM -0400, Lyude Paul wrote: > > > When reprobing an MST topology during resume, we have to account for the > > > fact that while we were suspended it's possible that mstbs may have been > > > removed from any

This patch convert rx mode setting to be done in a workqueue, this is a must for allow to sleep when waiting for the cvq command to response since current code is executed under addr spin lock. Signed-off-by: Jason Wang <jasowang at redhat.com> --- Changes since V1: - use RTNL to synchronize rx mode worker --- drivers/net/virtio_net.c | 55 +++++++++++++++++++++++++++++++++++++--- 1 file

When reprobing an MST topology during resume, we have to account for the fact that while we were suspended it's possible that mstbs may have been removed from any ports in the topology. Since iterating downwards in the topology requires that we hold &mgr->lock, destroying MSTBs from this context would result in attempting to lock &mgr->lock a second time and deadlocking. So, fix