similar to: [PATCH v3 0/2] vsock/virtio: fix issues on device hot-unplug

Avoid a race in which static variables in net/vmw_vsock/af_vsock.c are accessed (while handling interrupts) before they are initialized. [ 4.201410] BUG: unable to handle kernel paging request at ffffffffffffffe8 [ 4.207829] IP: vsock_addr_equals_addr+0x3/0x20 [ 4.211379] PGD 28210067 P4D 28210067 PUD 28212067 PMD 0 [ 4.211379] Oops: 0000 [#1] PREEMPT SMP PTI [ 4.211379] Modules

Avoid a race in which static variables in net/vmw_vsock/af_vsock.c are accessed (while handling interrupts) before they are initialized. [ 4.201410] BUG: unable to handle kernel paging request at ffffffffffffffe8 [ 4.207829] IP: vsock_addr_equals_addr+0x3/0x20 [ 4.211379] PGD 28210067 P4D 28210067 PUD 28212067 PMD 0 [ 4.211379] Oops: 0000 [#1] PREEMPT SMP PTI [ 4.211379] Modules

On Wed, May 01, 2019 at 03:08:31PM -0400, Stefan Hajnoczi wrote: > On Tue, Apr 30, 2019 at 05:30:01PM -0700, Jorge E. Moreira wrote: > > Avoid a race in which static variables in net/vmw_vsock/af_vsock.c are > > accessed (while handling interrupts) before they are initialized. > > > > > > [ 4.201410] BUG: unable to handle kernel paging request at

On Wed, May 01, 2019 at 03:08:31PM -0400, Stefan Hajnoczi wrote: > On Tue, Apr 30, 2019 at 05:30:01PM -0700, Jorge E. Moreira wrote: > > Avoid a race in which static variables in net/vmw_vsock/af_vsock.c are > > accessed (while handling interrupts) before they are initialized. > > > > > > [ 4.201410] BUG: unable to handle kernel paging request at

On Tue, May 07, 2019 at 02:25:43PM +0200, Stefano Garzarella wrote: > Hi Jorge, > > On Mon, May 06, 2019 at 01:19:55PM -0700, Jorge Moreira Broche wrote: > > > On Wed, May 01, 2019 at 03:08:31PM -0400, Stefan Hajnoczi wrote: > > > > On Tue, Apr 30, 2019 at 05:30:01PM -0700, Jorge E. Moreira wrote: > > > > > Avoid a race in which static variables in

On Tue, May 07, 2019 at 02:25:43PM +0200, Stefano Garzarella wrote: > Hi Jorge, > > On Mon, May 06, 2019 at 01:19:55PM -0700, Jorge Moreira Broche wrote: > > > On Wed, May 01, 2019 at 03:08:31PM -0400, Stefan Hajnoczi wrote: > > > > On Tue, Apr 30, 2019 at 05:30:01PM -0700, Jorge E. Moreira wrote: > > > > > Avoid a race in which static variables in

> On Wed, May 01, 2019 at 03:08:31PM -0400, Stefan Hajnoczi wrote: > > On Tue, Apr 30, 2019 at 05:30:01PM -0700, Jorge E. Moreira wrote: > > > Avoid a race in which static variables in net/vmw_vsock/af_vsock.c are > > > accessed (while handling interrupts) before they are initialized. > > > > > > > > > [ 4.201410] BUG: unable to handle

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

This series is based on Michael Tsirkin's vhost branch (v4.5-rc6). I'm about to process Claudio Imbrenda's locking fixes for virtio-vsock but first I want to share the latest version of the code. Several people are playing with vsock now so sharing the latest code should avoid duplicate work. v5: * Transport reset event for live migration support * Reorder virtqueues, drop unused

This series is based on Michael Tsirkin's vhost branch (v4.5-rc6). I'm about to process Claudio Imbrenda's locking fixes for virtio-vsock but first I want to share the latest version of the code. Several people are playing with vsock now so sharing the latest code should avoid duplicate work. v5: * Transport reset event for live migration support * Reorder virtqueues, drop unused

Note: the virtio-vsock device specification is currently under review but not yet finalized. Please review this code but don't merge until I send an update when the spec is finalized. Thanks! v3: * Remove unnecessary 3-way handshake, just do REQUEST/RESPONSE instead of REQUEST/RESPONSE/ACK * Remove SOCK_DGRAM support and focus on SOCK_STREAM first (also drop v2 Patch 1, it's

Note: the virtio-vsock device specification is currently under review but not yet finalized. Please review this code but don't merge until I send an update when the spec is finalized. Thanks! v3: * Remove unnecessary 3-way handshake, just do REQUEST/RESPONSE instead of REQUEST/RESPONSE/ACK * Remove SOCK_DGRAM support and focus on SOCK_STREAM first (also drop v2 Patch 1, it's

This series is based on v4.4-rc2 and the "virtio: make find_vqs() checkpatch.pl-friendly" patch I recently submitted. v4: * Addressed code review comments from Alex Bennee * MAINTAINERS file entries for new files * Trace events instead of pr_debug() * RST packet is sent when there is no listen socket * Allow guest->host connections again (began discussing netfilter support with

This series is based on v4.4-rc2 and the "virtio: make find_vqs() checkpatch.pl-friendly" patch I recently submitted. v4: * Addressed code review comments from Alex Bennee * MAINTAINERS file entries for new files * Trace events instead of pr_debug() * RST packet is sent when there is no listen socket * Allow guest->host connections again (began discussing netfilter support with

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