Received: by 2002:a25:ab43:0:0:0:0:0 with SMTP id u61csp116367ybi; Tue, 18 Jun 2019 18:43:53 -0700 (PDT) X-Google-Smtp-Source: APXvYqzBiP3XB0wPqEiuakvOamDRRb2SyAxXYv6clVaWFP9H2xq7/zaWGKEiyGcQUcRvynBp2kM6 X-Received: by 2002:a17:902:2865:: with SMTP id e92mr115180251plb.264.1560908633235; Tue, 18 Jun 2019 18:43:53 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1560908633; cv=none; d=google.com; s=arc-20160816; b=oOtJFQ35M+w6jGzmhxX3ou7xLmS7VZXDGmj67aEXakNwab5jujqGWgHP0b/RVWECrm UG7xhMYZEe0f2wNDofMIs945ows548I2BMKLzT9+K8+EtqWkeenj6t/3JDwIz0IKf4uF SLNGOXnsYc1dsnHGgcGMy6f/8XrYuoiMezKJkN2uDz3VnIXt7vVfZeiv7b+y3uvAXgUC L9VHV8ySrNc96rQo8dkVjW/3NTASsC5pV6yDdPQFel05wvL7ZNIgMZL1VUb2w9KBuCvI VZwnQl9EUanP1v2aSDc19nBHEiujp/zk0BOxrXXRMrDru2t3mnJhA1c0xjmwOCdHGsCA mfJw== 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=qArURfCq8pgJH/hmUIYqH2rVasxxMbBadfii47HgzEg=; b=EzqSJqE3YCGGL0IGaUIM0+E/7yLuLw/gfN9iwfYfV+jcvSzlE+Uu6ZQgPRmvqDWDz8 8Zx70xMeV6MKt3ZCafaJvoH/yuU6Cs1/QRo7c2fOYYdj8MGdCyfX5MPP4HxabIFsWY2D xjg9UuBFejLG8cHVEcPdb9Lyqy6bHEA6tMW4bIyftBOeUWIJklzHgMPE1mqx8kQ4tHIC rBVB72VcYuFkZcWme8GNS4ZxjPojqEhf1DpSZKvDP52JrnIsBT36mTNyht4kZbvkKNgF KbcZwvxuwYa87DjPxZKY3S94NVTQnB7acu6xT/sIeJaUs4FoMNc4ozWrpe+m5VQarqyL saLg== 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 n8si15195310pfa.223.2019.06.18.18.43.37; Tue, 18 Jun 2019 18:43:53 -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 S1729943AbfFSBms (ORCPT + 99 others); Tue, 18 Jun 2019 21:42:48 -0400 Received: from shards.monkeyblade.net ([23.128.96.9]:56378 "EHLO shards.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726047AbfFSBms (ORCPT ); Tue, 18 Jun 2019 21:42:48 -0400 Received: from localhost (unknown [8.46.76.24]) (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 7653014CC8ADE; Tue, 18 Jun 2019 18:42:36 -0700 (PDT) Date: Tue, 18 Jun 2019 21:42:32 -0400 (EDT) Message-Id: <20190618.214232.430281845003030631.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 net v2] hvsock: fix epollout hang from race condition 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]); Tue, 18 Jun 2019 18:42:47 -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: Mon, 17 Jun 2019 19:26:25 +0000 > Currently, hvsock can enter into a state where epoll_wait on EPOLLOUT will > not return even when the hvsock socket is writable, under some race > condition. This can happen under the following sequence: ... > Now, the EPOLLOUT will never return even if the socket write buffer is > empty. > > The fix is to set the pending size to the default size and never change it. > This way the host will always notify the guest whenever the writable space > is bigger than the pending size. The host is already optimized to *only* > notify the guest when the pending size threshold boundary is crossed and > not everytime. > > This change also reduces the cpu usage somewhat since hv_stream_has_space() > is in the hotpath of send: > vsock_stream_sendmsg()->hv_stream_has_space() > Earlier hv_stream_has_space was setting/clearing the pending size on every > call. > > Signed-off-by: Sunil Muthuswamy > Reviewed-by: Dexuan Cui > --- > - Resubmitting the patch after taking care of some spurious warnings. Applied and queued up for -stable.