From patchwork Tue Oct 27 17:18:22 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Marcelo Henrique Cerri X-Patchwork-Id: 1388804 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=none (no SPF record) smtp.mailfrom=lists.ubuntu.com (client-ip=91.189.94.19; helo=huckleberry.canonical.com; envelope-from=kernel-team-bounces@lists.ubuntu.com; receiver=) Authentication-Results: ozlabs.org; dmarc=fail (p=none dis=none) header.from=canonical.com Received: from huckleberry.canonical.com (huckleberry.canonical.com [91.189.94.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 4CLJMP49GDz9sRk; Wed, 28 Oct 2020 04:18:40 +1100 (AEDT) Received: from localhost ([127.0.0.1] helo=huckleberry.canonical.com) by huckleberry.canonical.com with esmtp (Exim 4.86_2) (envelope-from ) id 1kXScC-0007QR-N1; Tue, 27 Oct 2020 17:18:32 +0000 Received: from youngberry.canonical.com ([91.189.89.112]) by huckleberry.canonical.com with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.86_2) (envelope-from ) id 1kXSc9-0007QF-41 for kernel-team@lists.ubuntu.com; Tue, 27 Oct 2020 17:18:29 +0000 Received: from mail-qv1-f71.google.com ([209.85.219.71]) by youngberry.canonical.com with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.86_2) (envelope-from ) id 1kXSc8-0002Hq-Oz for kernel-team@lists.ubuntu.com; Tue, 27 Oct 2020 17:18:28 +0000 Received: by mail-qv1-f71.google.com with SMTP id k15so1229643qvx.4 for ; Tue, 27 Oct 2020 10:18:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:message-id:mime-version :content-transfer-encoding; bh=L0Cj9WfHO6oAI1Y9dkzYwpcvS5vM2ByNTD0uziIHfDA=; b=G53sWeKWtvXq5lR/bHzbWGpi5qRzqdObRjOqjeQH47T1QxsGYnq18vffeJ2gkpKo9x OwsufLfwg7V7t8nHjjnvl1XXt6WrJHfKFrCK+IIiKwpFLPRHIXI8OC0dAcpBuZXymySL xqMs5Kzun8sPwAi2+zjD3AYayAsmYfMUkSdM1gm6j7VMaB8IW9loX3bBt8Hj4RXsS1DP PcDPRqDCABEP08Ebk9ByyFSeMj2b4h0PAuQPgLllmbq+uai3U+BQO1/Mp8g6g4qh0Yip AAk/btTa2vYOKQR5q7HTPdTzssgYZv6QHUeDVv8RD3BXgaxV9d3PzNRiWxa+idbYl01Q EQ5w== X-Gm-Message-State: AOAM532C30Ka07rTs0utY1u3FmPRyVR1Rt2iKmi5B8PRP/TNYbiy6bHk XyoiJ1Iw6E0ajhJ/TBirEytcpufh3npC0NonyZ8LnDbkACOTydBxbFSEVF2lZ5qv6fIuBUiGNdY YjM8pQ4EjUmbrT6lgCHLPtuDC0VD7toeyjYzAupGc X-Received: by 2002:a05:620a:4:: with SMTP id j4mr3308170qki.164.1603819107090; Tue, 27 Oct 2020 10:18:27 -0700 (PDT) X-Google-Smtp-Source: ABdhPJx2F2RqYed28s6kqNIYb8cR4tVs/2OTB0tCgkA+ONNS3uDBbdf0aLQYaktJRRKgkQOUEfW0FA== X-Received: by 2002:a05:620a:4:: with SMTP id j4mr3308138qki.164.1603819106676; Tue, 27 Oct 2020 10:18:26 -0700 (PDT) Received: from valinor.lan (200-232-230-238.dsl.telesp.net.br. [200.232.230.238]) by smtp.gmail.com with ESMTPSA id k15sm1298109qtk.64.2020.10.27.10.18.24 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 27 Oct 2020 10:18:25 -0700 (PDT) From: Marcelo Henrique Cerri To: kernel-team@lists.ubuntu.com Subject: [focal:linux-azure][LP:#1894896][PATCH] hv_netvsc: Fix hibernation for mlx5 VF driver Date: Tue, 27 Oct 2020 14:18:22 -0300 Message-Id: <20201027171822.1575137-1-marcelo.cerri@canonical.com> X-Mailer: git-send-email 2.25.1 MIME-Version: 1.0 X-BeenThere: kernel-team@lists.ubuntu.com X-Mailman-Version: 2.1.20 Precedence: list List-Id: Kernel team discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kernel-team-bounces@lists.ubuntu.com Sender: "kernel-team" From: Dexuan Cui BugLink: https://bugs.launchpad.net/bugs/1894896 mlx5_suspend()/resume() keep the network interface, so during hibernation netvsc_unregister_vf() and netvsc_register_vf() are not called, and hence netvsc_resume() should call netvsc_vf_changed() to switch the data path back to the VF after hibernation. Note: after we close and re-open the vmbus channel of the netvsc NIC in netvsc_suspend() and netvsc_resume(), the data path is implicitly switched to the netvsc NIC. Similarly, netvsc_suspend() should not call netvsc_unregister_vf(), otherwise the VF can no longer be used after hibernation. For mlx4, since the VF network interafce is explicitly destroyed and re-created during hibernation (see mlx4_suspend()/resume()), hv_netvsc already explicitly switches the data path from and to the VF automatically via netvsc_register_vf() and netvsc_unregister_vf(), so mlx4 doesn't need this fix. Note: mlx4 can still work with the fix because in netvsc_suspend()/resume() ndev_ctx->vf_netdev is NULL for mlx4. Fixes: 0efeea5fb153 ("hv_netvsc: Add the support of hibernation") Signed-off-by: Dexuan Cui Signed-off-by: Jakub Kicinski (cherry picked from commit 19162fd4063a3211843b997a454b505edb81d5ce) Signed-off-by: Marcelo Henrique Cerri Acked-by: Stefan Bader --- Marcelo's comments: I was able to reproduce the problem with the current version from focal-updates following the test instructions from the LP bug and I was also able to confirm the fix solves the problem with a test kernel: https://kernel.ubuntu.com/~mhcerri/azure/focal-linux-azure_lp1894896.tgz 5.8 already received the fix via an upstream stable update (LP:#1894896) and hibernation is not supported in 4.15 linux-azure. Besides that the fix is a clean cherry-pick from upstream. --- drivers/net/hyperv/netvsc_drv.c | 16 +++++++++++----- 1 file changed, 11 insertions(+), 5 deletions(-) diff --git a/drivers/net/hyperv/netvsc_drv.c b/drivers/net/hyperv/netvsc_drv.c index 33d9d17ee0e0..be5ede2a6b94 100644 --- a/drivers/net/hyperv/netvsc_drv.c +++ b/drivers/net/hyperv/netvsc_drv.c @@ -2551,8 +2551,8 @@ static int netvsc_remove(struct hv_device *dev) static int netvsc_suspend(struct hv_device *dev) { struct net_device_context *ndev_ctx; - struct net_device *vf_netdev, *net; struct netvsc_device *nvdev; + struct net_device *net; int ret; net = hv_get_drvdata(dev); @@ -2568,10 +2568,6 @@ static int netvsc_suspend(struct hv_device *dev) goto out; } - vf_netdev = rtnl_dereference(ndev_ctx->vf_netdev); - if (vf_netdev) - netvsc_unregister_vf(vf_netdev); - /* Save the current config info */ ndev_ctx->saved_netvsc_dev_info = netvsc_devinfo_get(nvdev); @@ -2587,6 +2583,7 @@ static int netvsc_resume(struct hv_device *dev) struct net_device *net = hv_get_drvdata(dev); struct net_device_context *net_device_ctx; struct netvsc_device_info *device_info; + struct net_device *vf_netdev; int ret; rtnl_lock(); @@ -2599,6 +2596,15 @@ static int netvsc_resume(struct hv_device *dev) netvsc_devinfo_put(device_info); net_device_ctx->saved_netvsc_dev_info = NULL; + /* A NIC driver (e.g. mlx5) may keep the VF network interface across + * hibernation, but here the data path is implicitly switched to the + * netvsc NIC since the vmbus channel is closed and re-opened, so + * netvsc_vf_changed() must be used to switch the data path to the VF. + */ + vf_netdev = rtnl_dereference(net_device_ctx->vf_netdev); + if (vf_netdev && netvsc_vf_changed(vf_netdev) != NOTIFY_OK) + ret = -EINVAL; + rtnl_unlock(); return ret;