lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAGxU2F4WbFNgux7YaFgf4WnabJ9hAohVykpYPt6VWoais9areQ@mail.gmail.com>
Date:   Fri, 4 Jan 2019 15:25:16 +0100
From:   Stefano Garzarella <sgarzare@...hat.com>
To:     Stefan Hajnoczi <stefanha@...hat.com>
Cc:     netdev@...r.kernel.org, davem@...emloft.net
Subject: Re: [PATCH RFC 0/2] vsock/virtio: fix issues on device hot-unplug

On Fri, Jan 4, 2019 at 12:44 PM Stefan Hajnoczi <stefanha@...hat.com> wrote:
>
> On Thu, Dec 20, 2018 at 01:15:33PM +0100, Stefano Garzarella 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.
> >
> > 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.19.2
> >
>
> Fine in the current model.  Once we tackle nested virtualization
> (two transports at once) we'll have to revisit this.

I completely agree with you!

>
> Acked-by: Stefan Hajnoczi <stefanha@...hat.com>

I'll send a v2 fixing the commit message of patch 1.

Thanks,
Stefano

--
Stefano Garzarella
Red Hat

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ