similar to: [PATCH 0/4] vsock/virtio: several fixes in the .probe() and .remove()

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

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

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),

On 2019/5/31 ??4:18, Stefano Garzarella wrote: > On Thu, May 30, 2019 at 07:59:14PM +0800, Jason Wang wrote: >> 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/31 ??4:18, Stefano Garzarella wrote: > On Thu, May 30, 2019 at 07:59:14PM +0800, Jason Wang wrote: >> 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/6/6 ??4:11, Stefano Garzarella wrote: > On Fri, May 31, 2019 at 05:56:39PM +0800, Jason Wang wrote: >> On 2019/5/31 ??4:18, Stefano Garzarella wrote: >>> On Thu, May 30, 2019 at 07:59:14PM +0800, Jason Wang wrote: >>>> On 2019/5/30 ??6:10, Stefano Garzarella wrote: >>>>> On Thu, May 30, 2019 at 05:46:18PM +0800, Jason Wang wrote:

On 2019/6/28 ??8:36, Stefano Garzarella wrote: > Some callbacks used by the upper layers can run while we are in the > .remove(). A potential use-after-free can happen, because we free > the_virtio_vsock without knowing if the callbacks are over or not. > > To solve this issue we move the assignment of the_virtio_vsock at the > end of .probe(), when we finished all the

On 2019/6/28 ??8:36, Stefano Garzarella wrote: > Some callbacks used by the upper layers can run while we are in the > .remove(). A potential use-after-free can happen, because we free > the_virtio_vsock without knowing if the callbacks are over or not. > > To solve this issue we move the assignment of the_virtio_vsock at the > end of .probe(), when we finished all the

These patches try to handle the hot-unplug of vsock virtio transport device in a proper way. Maybe move the vsock_core_init()/vsock_core_exit() functions in the module_init and module_exit of vsock_virtio_transport module can't be the best way, but the architecture of vsock_core forces us to this approach for now. The vsock_core proto_ops expect a valid pointer to the transport device, so we

These patches try to handle the hot-unplug of vsock virtio transport device in a proper way. Maybe move the vsock_core_init()/vsock_core_exit() functions in the module_init and module_exit of vsock_virtio_transport module can't be the best way, but the architecture of vsock_core forces us to this approach for now. The vsock_core proto_ops expect a valid pointer to the transport device, so we

On 2019/7/3 ??6:41, Stefano Garzarella wrote: > On Wed, Jul 03, 2019 at 05:53:58PM +0800, Jason Wang wrote: >> On 2019/6/28 ??8:36, Stefano Garzarella wrote: >>> Some callbacks used by the upper layers can run while we are in the >>> .remove(). A potential use-after-free can happen, because we free >>> the_virtio_vsock without knowing if the callbacks are over

On 2019/7/3 ??6:41, Stefano Garzarella wrote: > On Wed, Jul 03, 2019 at 05:53:58PM +0800, Jason Wang wrote: >> On 2019/6/28 ??8:36, Stefano Garzarella wrote: >>> Some callbacks used by the upper layers can run while we are in the >>> .remove(). A potential use-after-free can happen, because we free >>> the_virtio_vsock without knowing if the callbacks are over

This series is based on v4.7. This RFC is the implementation for the new VIRTIO Socket device. It is developed in parallel with the VIRTIO device specification and proves the design. Once the specification has been accepted I will send a non-RFC version of this patch series. v6: * Add VHOST_VSOCK_SET_RUNNING ioctl to start/stop vhost cleanly * Add graceful shutdown to avoid port reuse while

This series is based on v4.7. This RFC is the implementation for the new VIRTIO Socket device. It is developed in parallel with the VIRTIO device specification and proves the design. Once the specification has been accepted I will send a non-RFC version of this patch series. v6: * Add VHOST_VSOCK_SET_RUNNING ioctl to start/stop vhost cleanly * Add graceful shutdown to avoid port reuse while