Received: by 10.213.65.68 with SMTP id h4csp2285849imn; Thu, 5 Apr 2018 12:11:55 -0700 (PDT) X-Google-Smtp-Source: AIpwx49XE10NLsnvFeByIrYg63Ab3sTUqhEg4OAZEd+M5udtG6vE5RoInZHUYUO9Y+Aj31+OuODW X-Received: by 10.98.163.68 with SMTP id s65mr18102504pfe.13.1522955515606; Thu, 05 Apr 2018 12:11:55 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1522955515; cv=none; d=google.com; s=arc-20160816; b=QFCE93pWmPDPEF16r5Bj5SwbfJgoPFFLKx5/2jn3GyWHAY/nnR1OyHstZFi8jMHZ0w A/Eb03oH4u5UeurGxPUr9/H71JBdJLjwYZwepvBe8Vl4sSYil4wcAJujwho20npZXKcz RmpwDRLq3dlcegjGEbLLGrmvqz3b147TW+fnvm6mvi2IfpdfEzz2+dKa0tUrW1BKfi9f ApHc9a8FdrCBQQowFSZ/Pjp9Um36/1w1uixO6ZYst2HhQD9QCZoXVn3WT1HyyK57Qwl+ MdieS24TD4L87kVcDvVSmGK68GDYKSci8yKE7mgI0mpdYMPm5kDa9YdJDNr6ONJcHGC5 DAZQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:references:in-reply-to:message-id:date :subject:cc:to:from:arc-authentication-results; bh=4h1EI/6JyRxq/Cg2yBS0Qc9r2jiZTPnCMHXtEKdHHVY=; b=MglXS9LfCr9f0RemKC+8U1uV3sNLzUihoinwKsv0ejvztiJUXxhnaKNxeutO6DmLtq btBpG1xaki7BUCzXy1E35BD8Me88GH5kWP/vvxGAGWxcdwiUh3OMgQ8AHfAc//k4CWnU pYFfdVJAUU4UdK/IFRMOwqlfxG0rMvbN0GGaj8LTYBhzM20QFVuWI7woDnPy28OvGfCz vuKDyBJLiTwcYSnn19c3GEmMi9eVigo4fHEs12xLVeABI7Ks5O+PQ1xJQ/04kRSllqAg +vxWc5w1fBgMRKUgAheyFKrsY1dbJQQrrR/Jlyd6ANVEIPdqKsNHMwZDWKB1hBVhzHjp 22CA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id x27si5823842pgc.4.2018.04.05.12.11.41; Thu, 05 Apr 2018 12:11:55 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752798AbeDETKN (ORCPT + 99 others); Thu, 5 Apr 2018 15:10:13 -0400 Received: from mx3-rdu2.redhat.com ([66.187.233.73]:36452 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1752383AbeDETJi (ORCPT ); Thu, 5 Apr 2018 15:09:38 -0400 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.rdu2.redhat.com [10.11.54.4]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 6056377067; Thu, 5 Apr 2018 19:09:37 +0000 (UTC) Received: from mmorsy.remote.csb (unknown [10.36.112.13]) by smtp.corp.redhat.com (Postfix) with ESMTP id 172062023235; Thu, 5 Apr 2018 19:09:34 +0000 (UTC) From: Mohammed Gamal To: netdev@vger.kernel.org, sthemmin@microsoft.com Cc: devel@linuxdriverproject.org, linux-kernel@vger.kernel.org, kys@microsoft.com, haiyangz@microsoft.com, vkuznets@redhat.com, otubo@redhat.com, Mohammed Gamal Subject: [PATCH 3/4] hv_netvsc: Ensure correct teardown message sequence order Date: Thu, 5 Apr 2018 21:09:20 +0200 Message-Id: <1522955361-14704-4-git-send-email-mgamal@redhat.com> In-Reply-To: <1522955361-14704-1-git-send-email-mgamal@redhat.com> References: <1522955361-14704-1-git-send-email-mgamal@redhat.com> X-Scanned-By: MIMEDefang 2.78 on 10.11.54.4 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.1]); Thu, 05 Apr 2018 19:09:37 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.1]); Thu, 05 Apr 2018 19:09:37 +0000 (UTC) for IP:'10.11.54.4' DOMAIN:'int-mx04.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'mgamal@redhat.com' RCPT:'' Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Prior to commit 0cf737808ae7 ("hv_netvsc: netvsc_teardown_gpadl() split") the call sequence in netvsc_device_remove() was as follows (as implemented in netvsc_destroy_buf()): 1- Send NVSP_MSG1_TYPE_REVOKE_RECV_BUF message 2- Teardown receive buffer GPADL 3- Send NVSP_MSG1_TYPE_REVOKE_SEND_BUF message 4- Teardown send buffer GPADL 5- Close vmbus This didn't work for WS2016 hosts. Commit 0cf737808ae7 ("hv_netvsc: netvsc_teardown_gpadl() split") rearranged the teardown sequence as follows: 1- Send NVSP_MSG1_TYPE_REVOKE_RECV_BUF message 2- Send NVSP_MSG1_TYPE_REVOKE_SEND_BUF message 3- Close vmbus 4- Teardown receive buffer GPADL 5- Teardown send buffer GPADL That worked well for WS2016 hosts, but it prevented guests on older hosts from shutting down after changing network settings. Commit 0ef58b0a05c1 ("hv_netvsc: change GPAD teardown order on older versions") ensured the following message sequence for older hosts 1- Send NVSP_MSG1_TYPE_REVOKE_RECV_BUF message 2- Send NVSP_MSG1_TYPE_REVOKE_SEND_BUF message 3- Teardown receive buffer GPADL 4- Teardown send buffer GPADL 5- Close vmbus However, with this sequence calling `ip link set eth0 mtu 1000` hangs and the process becomes uninterruptible. On futher analysis it turns out that on tearing down the receive buffer GPADL the kernel is waiting indefinitely in vmbus_teardown_gpadl() for a completion to be signaled. Here is a snippet of where this occurs: int vmbus_teardown_gpadl(struct vmbus_channel *channel, u32 gpadl_handle) { struct vmbus_channel_gpadl_teardown *msg; struct vmbus_channel_msginfo *info; unsigned long flags; int ret; info = kmalloc(sizeof(*info) + sizeof(struct vmbus_channel_gpadl_teardown), GFP_KERNEL); if (!info) return -ENOMEM; init_completion(&info->waitevent); info->waiting_channel = channel; [....] ret = vmbus_post_msg(msg, sizeof(struct vmbus_channel_gpadl_teardown), true); if (ret) goto post_msg_err; wait_for_completion(&info->waitevent); [....] } The completion is signaled from vmbus_ongpadl_torndown(), which gets called when the corresponding message is received from the host, which apparently never happens in that case. This patch works around the issue by restoring the first mentioned message sequence for older hosts Fixes: 0ef58b0a05c1 ("hv_netvsc: change GPAD teardown order on older versions") Signed-off-by: Mohammed Gamal --- drivers/net/hyperv/netvsc.c | 19 +++++++++++++------ 1 file changed, 13 insertions(+), 6 deletions(-) diff --git a/drivers/net/hyperv/netvsc.c b/drivers/net/hyperv/netvsc.c index f4df5de..df92c2f 100644 --- a/drivers/net/hyperv/netvsc.c +++ b/drivers/net/hyperv/netvsc.c @@ -592,8 +592,17 @@ void netvsc_device_remove(struct hv_device *device) = rtnl_dereference(net_device_ctx->nvdev); int i; + /* + * Revoke receive buffer. If host is pre-Win2016 then tear down + * receive buffer GPADL. Do the same for send buffer. + */ netvsc_revoke_recv_buf(device, net_device); + if (vmbus_proto_version < VERSION_WIN10) + netvsc_teardown_recv_gpadl(device, net_device); + netvsc_revoke_send_buf(device, net_device); + if (vmbus_proto_version < VERSION_WIN10) + netvsc_teardown_send_gpadl(device, net_device); RCU_INIT_POINTER(net_device_ctx->nvdev, NULL); @@ -607,15 +616,13 @@ void netvsc_device_remove(struct hv_device *device) */ netdev_dbg(ndev, "net device safe to remove\n"); - /* older versions require that buffer be revoked before close */ - if (vmbus_proto_version < VERSION_WIN10) { - netvsc_teardown_recv_gpadl(device, net_device); - netvsc_teardown_send_gpadl(device, net_device); - } - /* Now, we can close the channel safely */ vmbus_close(device->channel); + /* + * If host is Win2016 or higher then we do the GPADL tear down + * here after VMBus is closed. + */ if (vmbus_proto_version >= VERSION_WIN10) { netvsc_teardown_recv_gpadl(device, net_device); netvsc_teardown_send_gpadl(device, net_device); -- 1.8.3.1