From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7C9FCC169C4 for ; Tue, 29 Jan 2019 15:34:11 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 4A4F821473 for ; Tue, 29 Jan 2019 15:34:11 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727042AbfA2PeK (ORCPT ); Tue, 29 Jan 2019 10:34:10 -0500 Received: from mail-ot1-f65.google.com ([209.85.210.65]:44182 "EHLO mail-ot1-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725747AbfA2PeK (ORCPT ); Tue, 29 Jan 2019 10:34:10 -0500 Received: by mail-ot1-f65.google.com with SMTP id g16so14195442otg.11 for ; Tue, 29 Jan 2019 07:34:09 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=0XDVOlIj11SEC3QDS1d0J+znS3KkHtwDV1bDCFBqJok=; b=ZyAu6Yc7CdvqGvUMiUD9moh939MIJ7wlgNKHubeFIPeRR4lIkYO8KDMlw1+2Y+/A5N aX5rpomCxbmHtMA7hg9Y3f9ReyRddDD4c0CYahAj1RHLn/OTn94ppvZWQTqUQtlbgNEU aR5l+5jxcR2DuQQTY6o8vLSPlnUvH2SOk/GnDK90505MlrfvkchXd8G3y+uQO+wrAfLh KfkJc0smCjXKtTjJxyxRL4ALTFoK3kK7mzhZiY1n6X+rsLVAPMoLonwloDcv0HvsWvFM EVLHdtRD8JGII0nBjOdyUPwHNWECiHBunC47g1C+lkzdOO+BAth83VY0dV4vg15+gNlM mM8Q== X-Gm-Message-State: AJcUukcN1i1yM86nCoYzxtN4YyHvJRqIDz6rA2GmoOmMewdwdHo93NgC ohd1Qk/82FmrYMQvBAGMEaoR/S4CkWgF4Fnprv+opg== X-Google-Smtp-Source: ALg8bN4tF2fy3+EjEovfzwlFOxw1LMF1HzpY8AAQtxWsj0FJQAFEM5ERcBioW51CIk1ciugJYSnci2SwTR+mf6FiFwk= X-Received: by 2002:a9d:67cf:: with SMTP id c15mr18838702otn.38.1548776049211; Tue, 29 Jan 2019 07:34:09 -0800 (PST) MIME-Version: 1.0 References: <20190104143411.95519-1-sgarzare@redhat.com> In-Reply-To: <20190104143411.95519-1-sgarzare@redhat.com> From: Stefano Garzarella Date: Tue, 29 Jan 2019 16:33:58 +0100 Message-ID: Subject: Re: [PATCH RFC v2 0/2] vsock/virtio: fix issues on device hot-unplug To: davem@davemloft.net, netdev@vger.kernel.org Cc: Stefan Hajnoczi Content-Type: text/plain; charset="UTF-8" Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org Kindly ping :) On Fri, Jan 4, 2019 at 3:34 PM 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. > > 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 >