Received: by 10.223.176.5 with SMTP id f5csp2460313wra; Thu, 1 Feb 2018 00:39:08 -0800 (PST) X-Google-Smtp-Source: AH8x225XnbuGyuKZPhL0xVi2KJBJaAuRGn9nDgdEPOOXIOhcsXSU9KVz4ru1WDwpba9tuPA9OApC X-Received: by 10.99.179.77 with SMTP id x13mr27068385pgt.135.1517474347905; Thu, 01 Feb 2018 00:39:07 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1517474347; cv=none; d=google.com; s=arc-20160816; b=goxe5xfEeYx4t7Q+7Ap1kpFsNxMcMJpO7DgpwNICO7o6DDTHF+bQ35aN70gIsHfk6c b685/YvJoTcduRp7T1RcX2u8h5kyPQ3++gwkuMNX3fX1GgCUgqmDTjWm+MMTaZZAC7JV xQGExijKHbQ3Ejso+2aWu7JpWAXh8XjVh8L9q0lB35w0Vs2Ono2SFN5+W8dT/lGpDx0O Y1lMBeBx3qimTnu7deoRQ1GYL8iXZTQOraHuCNuu0qXynZE/mHZMNCWOl3v9EjjJu3r7 +5KkSXsUF+eDhQKfM0eoR0GWuOMcz+cjXCdHmX1garMqn0WsAY7GkJkN5vrFV6Xo3JRm S/VA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :organization:references:in-reply-to:date:cc:to:reply-to:from :subject:message-id:arc-authentication-results; bh=mBxPzJCgmeZaQa8kRuP0KPvObkxWtmm9IhJ79cv/4Es=; b=SRMVLsxFkmhX3IxVKvUIjl3IhkMzAr9W9MuphSL4w/jqm1JAgXDXzOeytBAiGFuBd9 NUSIiWmrLems9Pwpa58q1TL1NJW1TM+Vd4XooiMl4XjuH+0DZNDs6SdAYw5N/aHF6MSg yiHYOQOFBirbNoGIak8T9GavwiM/J0SpDYjaooGWwxfPWULsm1QmPWKZ4OGC+HMxo6u3 mJTmVKV7u/Hy15jMb+h5JcxuNpg7W55nTBxslGnmkLN+uXQmNInthMODt5do8pghg+BR ltyam1Wil+u0ydLGhBeZxWZMuh6SGGgJ909+dGPUxl3M9KAvoqo8BvQeQjDOufi2M2NP aCmA== 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 f192si4020693pfc.68.2018.02.01.00.38.52; Thu, 01 Feb 2018 00:39:07 -0800 (PST) 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 S1751849AbeBAIha (ORCPT + 99 others); Thu, 1 Feb 2018 03:37:30 -0500 Received: from mx1.redhat.com ([209.132.183.28]:37280 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751399AbeBAIh0 (ORCPT ); Thu, 1 Feb 2018 03:37:26 -0500 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id B020A155DB; Thu, 1 Feb 2018 08:37:26 +0000 (UTC) Received: from ovpn-204-187.brq.redhat.com (ovpn-204-187.brq.redhat.com [10.40.204.187]) by smtp.corp.redhat.com (Postfix) with ESMTP id 697956560E; Thu, 1 Feb 2018 08:37:21 +0000 (UTC) Message-ID: <1517474239.30443.2.camel@redhat.com> Subject: Re: [RFC PATCH 1/2] hv_netvsc: Split netvsc_revoke_buf() and netvsc_teardown_gpadl() From: Mohammed Gamal Reply-To: mgamal@redhat.com To: Stephen Hemminger Cc: netdev@vger.kernel.org, otubo@redhat.com, sthemmin@microsoft.com, haiyangz@microsoft.com, linux-kernel@vger.kernel.org, devel@linuxdriverproject.org, vkuznets@redhat.com Date: Thu, 01 Feb 2018 09:37:19 +0100 In-Reply-To: <20180131150137.58abee5b@xeon-e3> References: <1516700045-32142-1-git-send-email-mgamal@redhat.com> <1516700045-32142-2-git-send-email-mgamal@redhat.com> <20180130112926.53f3c166@xeon-e3> <1517397409.3452.7.camel@redhat.com> <20180131150137.58abee5b@xeon-e3> Organization: Red Hat Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.29]); Thu, 01 Feb 2018 08:37:26 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 2018-01-31 at 15:01 -0800, Stephen Hemminger wrote: > On Wed, 31 Jan 2018 12:16:49 +0100 > Mohammed Gamal wrote: > > > On Tue, 2018-01-30 at 11:29 -0800, Stephen Hemminger wrote: > > > On Tue, 23 Jan 2018 10:34:04 +0100 > > > Mohammed Gamal wrote: > > >    > > > > Split each of the functions into two for each of send/recv > > > > buffers > > > > > > > > Signed-off-by: Mohammed Gamal    > > > > > > Splitting these functions is not necessary   > > > > How so? We need to send each message independently, and hence the > > split > > (see cover letter). Is there another way? > > This is all that is needed. > > > Subject: [PATCH] hv_netvsc: work around for gpadl teardown on older > windows >  server > > On WS2012 the host ignores messages after vmbus channel is closed. > Workaround this by doing what Windows does and send the teardown > before close on older versions of NVSP protocol. > > Reported-by: Mohammed Gamal > Fixes: 0cf737808ae7 ("hv_netvsc: netvsc_teardown_gpadl() split") > Signed-off-by: Stephen Hemminger > --- >  drivers/net/hyperv/netvsc.c | 9 ++++++++- >  1 file changed, 8 insertions(+), 1 deletion(-) > > diff --git a/drivers/net/hyperv/netvsc.c > b/drivers/net/hyperv/netvsc.c > index 17e529af79dc..1a3df0eff42f 100644 > --- a/drivers/net/hyperv/netvsc.c > +++ b/drivers/net/hyperv/netvsc.c > @@ -574,10 +574,17 @@ void netvsc_device_remove(struct hv_device > *device) >    */ >   netdev_dbg(ndev, "net device safe to remove\n"); >   > + /* Workaround for older versions of Windows require that > +  * buffer be revoked before channel is disabled > +  */ > + if (net_device->nvsp_version < NVSP_PROTOCOL_VERSION_4) > + netvsc_teardown_gpadl(device, net_device); > + >   /* Now, we can close the channel safely */ >   vmbus_close(device->channel); >   > - netvsc_teardown_gpadl(device, net_device); > + if (net_device->nvsp_version >= NVSP_PROTOCOL_VERSION_4) > + netvsc_teardown_gpadl(device, net_device); >   >   /* And dissassociate NAPI context from device */ >   for (i = 0; i < net_device->num_chn; i++) I've tried a similar workaround before by calling netvsc_teardown_gpadl() after netvsc_revoke_buf(), but before setting net_device_ctx->nvdev to NULL and it caused the guest to hang when trying to change MTU.  Let me try that change and see if it behaves differently.