Received: by 2002:ac0:a594:0:0:0:0:0 with SMTP id m20-v6csp2007062imm; Thu, 24 May 2018 04:25:01 -0700 (PDT) X-Google-Smtp-Source: AB8JxZpFvKer5ISuE5+GV6eq0nnG9ncDMbeE1mkjPuZEiwfMbkr1oUoYKs+at1mKz4o8KUoEYoD2 X-Received: by 2002:a17:902:b087:: with SMTP id p7-v6mr6940221plr.227.1527161101614; Thu, 24 May 2018 04:25:01 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1527161101; cv=none; d=google.com; s=arc-20160816; b=bgoP6T7WHJm5bVs7yGf6BEWru6yti788sGW8AOW+yrh+JjASy0ZNtkLQ2xe5NtaGB0 8tC4NHwUWpfNkXpeEF0+j5OqCPL6uE7aUCvXcKwiMFb9Fqnx8zkhRWNVJdmbGbTozR3A t73BP9odTHVGShTyq/Klk23Oy52nBtk/MSMRdTn8rqcbSOrMRqm8KLTtCpY4265WXFx/ FQj2peN8coElwnrRswYB4+zlW3peZeE9xj2UEWAMLb4G66vLMjtBJZfoS+AwtAK4NI7B rQ88iulchWtDuAi3ikCi8BWRCuXNA9o+KIUdrQZRSqL1piKJ7sONm82twtDHC/t88wBd FnAA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:references :in-reply-to:message-id:date:subject:cc:to:from:dkim-signature :arc-authentication-results; bh=ZS5CbUj0fMVvkY3MiD9nrpCrAi7qEe8pMW+DB5GLRwo=; b=MBxXymXCrQz0Xpv9IVPnyHw8/WhUbjgj2GctKVnnyQfkaG2h4ByeoL+CRWKYJqh8bJ xzXD7vrpAxK9Y9/rQTU8IROg3lw7zs3ovDiji8eazcI9+Byva2+U8wCRbJKUtcQXOczC si885XR9c8gR1MDmbBs4TiEkYO801WnDJTCg8WZ5xZctWieGwRPix1hy3N+pU4Y3XvZx 04qB5NrviI6nJv3YT/B9NqvxTIfMCyWfc8get07bSjrs2lCQeolum0bvyjuMT0Ivjqcy YO4oVmEyju7DUScBodEoPZcPhzzy/gaR9Oo0TLrXMU5KSjoR66MhfZgg66iMn+G+CICX 1jUg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=cWHObIqf; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id v7-v6si8490705pgo.135.2018.05.24.04.24.46; Thu, 24 May 2018 04:25:01 -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; dkim=pass header.i=@kernel.org header.s=default header.b=cWHObIqf; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S967223AbeEXJv7 (ORCPT + 99 others); Thu, 24 May 2018 05:51:59 -0400 Received: from mail.kernel.org ([198.145.29.99]:48360 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S967380AbeEXJvz (ORCPT ); Thu, 24 May 2018 05:51:55 -0400 Received: from localhost (LFbn-1-12247-202.w90-92.abo.wanadoo.fr [90.92.61.202]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 0AFB920847; Thu, 24 May 2018 09:51:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1527155514; bh=m3OcXRWoDACKlBo6mHtnsQrB1whCim/Vta1b6BErIqg=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=cWHObIqfEp0eQCbsBXrw0XVaPrWvvCRe93zhRDDjG7Us3OMRWikhtgnWvCT4khoH1 c12+6s19+lEptEtMYcB2YCuW/oYVlrdWQI8wwchbZBMYhd4BXJqEEDnZa1hyQpTe1V cG2XaJQBnvyKS4ti1rtWzdj1jImJHBkf1b1E+cMA= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Vitaly Kuznetsov , "David S. Miller" Subject: [PATCH 4.14 017/165] hv_netvsc: netvsc_teardown_gpadl() split Date: Thu, 24 May 2018 11:37:03 +0200 Message-Id: <20180524093622.678940144@linuxfoundation.org> X-Mailer: git-send-email 2.17.0 In-Reply-To: <20180524093621.979359379@linuxfoundation.org> References: <20180524093621.979359379@linuxfoundation.org> User-Agent: quilt/0.65 X-stable: review MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 4.14-stable review patch. If anyone has any objections, please let me know. ------------------ From: Vitaly Kuznetsov [ Commit 0cf737808ae7cb25e952be619db46b9147a92f46 upstream. ] It was found that in some cases host refuses to teardown GPADL for send/ receive buffers (probably when some work with these buffere is scheduled or ongoing). Change the teardown logic to be: 1) Send NVSP_MSG1_TYPE_REVOKE_* messages 2) Close the channel 3) Teardown GPADLs. This seems to work reliably. Signed-off-by: Vitaly Kuznetsov Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman --- drivers/net/hyperv/netvsc.c | 69 ++++++++++++++++++++++---------------------- 1 file changed, 36 insertions(+), 33 deletions(-) --- a/drivers/net/hyperv/netvsc.c +++ b/drivers/net/hyperv/netvsc.c @@ -100,12 +100,11 @@ static void free_netvsc_device_rcu(struc call_rcu(&nvdev->rcu, free_netvsc_device); } -static void netvsc_destroy_buf(struct hv_device *device) +static void netvsc_revoke_buf(struct hv_device *device, + struct netvsc_device *net_device) { struct nvsp_message *revoke_packet; struct net_device *ndev = hv_get_drvdata(device); - struct net_device_context *ndc = netdev_priv(ndev); - struct netvsc_device *net_device = rtnl_dereference(ndc->nvdev); int ret; /* @@ -148,28 +147,6 @@ static void netvsc_destroy_buf(struct hv net_device->recv_section_cnt = 0; } - /* Teardown the gpadl on the vsp end */ - if (net_device->recv_buf_gpadl_handle) { - ret = vmbus_teardown_gpadl(device->channel, - net_device->recv_buf_gpadl_handle); - - /* If we failed here, we might as well return and have a leak - * rather than continue and a bugchk - */ - if (ret != 0) { - netdev_err(ndev, - "unable to teardown receive buffer's gpadl\n"); - return; - } - net_device->recv_buf_gpadl_handle = 0; - } - - if (net_device->recv_buf) { - /* Free up the receive buffer */ - vfree(net_device->recv_buf); - net_device->recv_buf = NULL; - } - /* Deal with the send buffer we may have setup. * If we got a send section size, it means we received a * NVSP_MSG1_TYPE_SEND_SEND_BUF_COMPLETE msg (ie sent @@ -210,7 +187,35 @@ static void netvsc_destroy_buf(struct hv } net_device->send_section_cnt = 0; } - /* Teardown the gpadl on the vsp end */ +} + +static void netvsc_teardown_gpadl(struct hv_device *device, + struct netvsc_device *net_device) +{ + struct net_device *ndev = hv_get_drvdata(device); + int ret; + + if (net_device->recv_buf_gpadl_handle) { + ret = vmbus_teardown_gpadl(device->channel, + net_device->recv_buf_gpadl_handle); + + /* If we failed here, we might as well return and have a leak + * rather than continue and a bugchk + */ + if (ret != 0) { + netdev_err(ndev, + "unable to teardown receive buffer's gpadl\n"); + return; + } + net_device->recv_buf_gpadl_handle = 0; + } + + if (net_device->recv_buf) { + /* Free up the receive buffer */ + vfree(net_device->recv_buf); + net_device->recv_buf = NULL; + } + if (net_device->send_buf_gpadl_handle) { ret = vmbus_teardown_gpadl(device->channel, net_device->send_buf_gpadl_handle); @@ -425,7 +430,8 @@ static int netvsc_init_buf(struct hv_dev goto exit; cleanup: - netvsc_destroy_buf(device); + netvsc_revoke_buf(device, net_device); + netvsc_teardown_gpadl(device, net_device); exit: return ret; @@ -544,11 +550,6 @@ cleanup: return ret; } -static void netvsc_disconnect_vsp(struct hv_device *device) -{ - netvsc_destroy_buf(device); -} - /* * netvsc_device_remove - Callback when the root bus device is removed */ @@ -562,7 +563,7 @@ void netvsc_device_remove(struct hv_devi cancel_work_sync(&net_device->subchan_work); - netvsc_disconnect_vsp(device); + netvsc_revoke_buf(device, net_device); RCU_INIT_POINTER(net_device_ctx->nvdev, NULL); @@ -575,6 +576,8 @@ void netvsc_device_remove(struct hv_devi /* Now, we can close the channel safely */ vmbus_close(device->channel); + netvsc_teardown_gpadl(device, net_device); + /* And dissassociate NAPI context from device */ for (i = 0; i < net_device->num_chn; i++) netif_napi_del(&net_device->chan_table[i].napi);