Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp1000665yba; Thu, 16 May 2019 12:27:00 -0700 (PDT) X-Google-Smtp-Source: APXvYqwwmQ196jUi9nj8zhD3LKFzxq8LSYo/q/RPmzfX9L3KHV7h9DMAW1uCbsVzkmk8yp5mePak X-Received: by 2002:a62:1cd5:: with SMTP id c204mr16947246pfc.205.1558034820020; Thu, 16 May 2019 12:27:00 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1558034820; cv=none; d=google.com; s=arc-20160816; b=ox8Rx0PPWTjGyG5f/Fj0PsEJp2P563EzCvuCTeqTtfWXHPyyWImLJ4Pw3ueOSBbXYe Q5SAvOqPyUqLKCC0Sn8fGqx34fTib9oIFf4AwugwoWRjkgwvDkE+Rxbdv0tsKDAqZQHQ qJvzPqoOLfP9aQhCNAZRO0zkJdToPHptEZR8keOMi9WxwTPv/7HiyMkcJROxYpf1NfM8 Pzw4/5XOQjB6R9opRqm67mJ5UYtSUoaDjA9D+gfYoyn4hb2cV5CN8zEt5/c4tX7NccPV FYReEO//6ULn1zAPDEHKX5sqjyKyz4ZsZEhmSFqDBc/xKn3v/Aah47QMtc0r7uXWCMJz +CHA== 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 :references:in-reply-to:from:subject:cc:to:message-id:date; bh=IbrjnJdFul2ndpQaJdg/DQhq58roCkItv+GO/3756G0=; b=yu/WF8OA3Ts3nzCv7imWaYmFzdYrVJdBd+zpUtfZ/MiKkBewJ6V6a8YrLsA11fZnKg eED1EgXjKpoX8W5oS/5wj7YNDN+K8U4+Phx6520NkBIpo5qwMu0hn3hwedePiSG11Sxu rkP3XOCmMt4kdDSBTLc8dF0fy26u6I88TcD6pnBT/U6xjql1zYs7f2wWda9M9wEX7ijc Q9n4QAHsIvSyEfsdcKlqAegv8343bmLIHC5wLac/HDJG/gApSgK3wj1PpdWG0qkqhCQv VtaQ6XNrW/E1akJZnjvhdbIDKFebUl0qUujY0M9vXjML2YmOc+QzAFcCq+yNbCZV+Ps1 xpMw== 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id y63si1571571pgd.567.2019.05.16.12.26.44; Thu, 16 May 2019 12:27:00 -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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727302AbfEPTME (ORCPT + 99 others); Thu, 16 May 2019 15:12:04 -0400 Received: from shards.monkeyblade.net ([23.128.96.9]:60074 "EHLO shards.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726317AbfEPTME (ORCPT ); Thu, 16 May 2019 15:12:04 -0400 Received: from localhost (unknown [IPv6:2601:601:9f80:35cd::3d8]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) (Authenticated sender: davem-davemloft) by shards.monkeyblade.net (Postfix) with ESMTPSA id 325AE133E977D; Thu, 16 May 2019 12:12:03 -0700 (PDT) Date: Thu, 16 May 2019 12:12:02 -0700 (PDT) Message-Id: <20190516.121202.232705215173348273.davem@davemloft.net> To: sunilmut@microsoft.com Cc: kys@microsoft.com, haiyangz@microsoft.com, sthemmin@microsoft.com, sashal@kernel.org, decui@microsoft.com, mikelley@microsoft.com, netdev@vger.kernel.org, linux-hyperv@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2] hv_sock: Add support for delayed close From: David Miller In-Reply-To: References: X-Mailer: Mew version 6.8 on Emacs 26.1 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.5.12 (shards.monkeyblade.net [149.20.54.216]); Thu, 16 May 2019 12:12:03 -0700 (PDT) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Sunil Muthuswamy Date: Wed, 15 May 2019 00:56:05 +0000 > Currently, hvsock does not implement any delayed or background close > logic. Whenever the hvsock socket is closed, a FIN is sent to the peer, and > the last reference to the socket is dropped, which leads to a call to > .destruct where the socket can hang indefinitely waiting for the peer to > close it's side. The can cause the user application to hang in the close() > call. > > This change implements proper STREAM(TCP) closing handshake mechanism by > sending the FIN to the peer and the waiting for the peer's FIN to arrive > for a given timeout. On timeout, it will try to terminate the connection > (i.e. a RST). This is in-line with other socket providers such as virtio. > > This change does not address the hang in the vmbus_hvsock_device_unregister > where it waits indefinitely for the host to rescind the channel. That > should be taken up as a separate fix. > > Signed-off-by: Sunil Muthuswamy Applied, thanks.