mbox series

[RFC,v2,0/2] vsock/virtio: fix issues on device hot-unplug

Message ID 20190104143411.95519-1-sgarzare@redhat.com
Headers show
Series vsock/virtio: fix issues on device hot-unplug | expand

Message

Stefano Garzarella Jan. 4, 2019, 2:34 p.m. UTC
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
can't call vsock_core_exit() until there are open sockets.

Another (little more complex) approach during the device removal, could be to
unregister the AF_VSOCK protocol, then reset all sockets and wait for their
destruction. At this point, we can set the transport pointer to NULL.

Any suggestions would be helpful.

v1 -> v2:
 - Fixed commit message of patch 1.

Stefano Garzarella (2):
  vsock/virtio: fix kernel panic after device hot-unplug
  vsock/virtio: reset connected sockets on device removal

 net/vmw_vsock/virtio_transport.c | 29 +++++++++++++++++++++--------
 1 file changed, 21 insertions(+), 8 deletions(-)

Comments

Stefano Garzarella Jan. 29, 2019, 3:33 p.m. UTC | #1
Kindly ping :)

On Fri, Jan 4, 2019 at 3:34 PM Stefano Garzarella <sgarzare@redhat.com> wrote:
>
> 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
> can't call vsock_core_exit() until there are open sockets.
>
> Another (little more complex) approach during the device removal, could be to
> unregister the AF_VSOCK protocol, then reset all sockets and wait for their
> destruction. At this point, we can set the transport pointer to NULL.
>
> Any suggestions would be helpful.
>
> v1 -> v2:
>  - Fixed commit message of patch 1.
>
> Stefano Garzarella (2):
>   vsock/virtio: fix kernel panic after device hot-unplug
>   vsock/virtio: reset connected sockets on device removal
>
>  net/vmw_vsock/virtio_transport.c | 29 +++++++++++++++++++++--------
>  1 file changed, 21 insertions(+), 8 deletions(-)
>
> --
> 2.20.1
>
Stefan Hajnoczi Feb. 1, 2019, 8:19 a.m. UTC | #2
On Tue, Jan 29, 2019 at 04:33:58PM +0100, Stefano Garzarella wrote:
> Kindly ping :)

Hi Stefano,
It probably didn't get picked up due to the "RFC" (Request for
Comments).

I suggest rebasing, retesting, and resending to be sure it will be
noticed and merged without conflicts.

Stefan
Stefano Garzarella Feb. 1, 2019, 8:44 a.m. UTC | #3
On Fri, Feb 01, 2019 at 04:19:41PM +0800, Stefan Hajnoczi wrote:
> On Tue, Jan 29, 2019 at 04:33:58PM +0100, Stefano Garzarella wrote:
> > Kindly ping :)
>
> Hi Stefano,
> It probably didn't get picked up due to the "RFC" (Request for
> Comments).
>
> I suggest rebasing, retesting, and resending to be sure it will be
> noticed and merged without conflicts.
>

Hi Stefan,
I will send a v3 following your suggestions!

Thanks,
Stefano