Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp422346pxb; Wed, 3 Mar 2021 06:42:37 -0800 (PST) X-Google-Smtp-Source: ABdhPJzV1aZkWnUMIxZ9en3GQrVSRUu16cAUUg8lq967D9v/YOumVJV4cs5O0JkzMndDNSliEA7g X-Received: by 2002:a05:6402:497:: with SMTP id k23mr25361511edv.315.1614782557758; Wed, 03 Mar 2021 06:42:37 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1614782557; cv=none; d=google.com; s=arc-20160816; b=klbyxA0U/ynEaSkb/xcKVP3YEPdq1XR7MeI6+llEVBy9wmLKkuif4UQ5tf2tHp5dQt qHWstURdgRlRhc1bGZmNMJnCHWR4gki4IhvbsjmdEmyMxgcrQA6b/sKo7s+PDtaWaH7w 5hgajaUxMORXH5qciNJVKUBvvguOOuQD3tY6bOBWtmfzJoShQid2mIE7agk4wdgUhWc/ O1IY5jdWnOSDPZEylIeu7AposhEpmYJ1wHNZLN90FzPTZJg3T4FeTv9rMhSsk8B8cnrb Nv4lLzvzyYo1fNhfqPmZlp8V7nJfhz/pB4f57lPad/XDSYesDCpWT+zYGcKNQMluQstj dqTg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=09PaEJcDWcIoyZkcBVFo3WKWY2yY3Hn62jOnOyTx858=; b=IGZ5yKrvuaRCpVVino72t7af40fSQWzNCzZ0U++74adUFDbg1G2lyb6gSQBcvycDOH HGStMSjYbh3d39WJHJTBJPFY1gEmKDvFkUhyvUlWYd4GM4tSsAy7E98ubbZh35afLpwG C3SpEhd2upOUmX4sCgz3OmBLXkoidTa4o6VXMWAbwq7b3kDuVvvUAv34FXk6nO5LCdVX 4If6I/HRdTLTNawZ492XrOmEAvhynZdoIuIKl6xqeQgOmiyvraFnMVfA06c8cPAicqyK vnJsh1JSLAEbjxAzv2LlRnsiUOD0P9D1V80pO4YGXCmqBh+nul7tacln6Kjjo1gOwv24 hKMQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=1vRRE8Lo; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id r25si2786261ejs.195.2021.03.03.06.41.45; Wed, 03 Mar 2021 06:42:37 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=1vRRE8Lo; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S244822AbhCAV6j (ORCPT + 99 others); Mon, 1 Mar 2021 16:58:39 -0500 Received: from mail.kernel.org ([198.145.29.99]:48856 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231959AbhCARYc (ORCPT ); Mon, 1 Mar 2021 12:24:32 -0500 Received: by mail.kernel.org (Postfix) with ESMTPSA id E6C1065075; Mon, 1 Mar 2021 16:49:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1614617398; bh=NULzpY5MMmstdlH2KexPOpYrdZRijabAP+ZtXO24c+s=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=1vRRE8LokF6kwvSMd/2Wk2RIBFvMztkqKP+0Uf9d+ZgFchihqRLHjEe57PyoYsZr6 08SzTi8cebsBqybLG7LdgK1C++vfLbbjBklwMjJ3Ia6Nc529SN+AZcRfim1EW4+BoH YGFd0RWgBDwNwdcELWVHh6bb/0fHzqnwFCwyc3TQ= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Eric Dumazet , Arjun Roy , Wei Wang , "David S. Miller" , Sasha Levin Subject: [PATCH 5.4 059/340] tcp: fix SO_RCVLOWAT related hangs under mem pressure Date: Mon, 1 Mar 2021 17:10:03 +0100 Message-Id: <20210301161051.222921226@linuxfoundation.org> X-Mailer: git-send-email 2.30.1 In-Reply-To: <20210301161048.294656001@linuxfoundation.org> References: <20210301161048.294656001@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Eric Dumazet [ Upstream commit f969dc5a885736842c3511ecdea240fbb02d25d9 ] While commit 24adbc1676af ("tcp: fix SO_RCVLOWAT hangs with fat skbs") fixed an issue vs too small sk_rcvbuf for given sk_rcvlowat constraint, it missed to address issue caused by memory pressure. 1) If we are under memory pressure and socket receive queue is empty. First incoming packet is allowed to be queued, after commit 76dfa6082032 ("tcp: allow one skb to be received per socket under memory pressure") But we do not send EPOLLIN yet, in case tcp_data_ready() sees sk_rcvlowat is bigger than skb length. 2) Then, when next packet comes, it is dropped, and we directly call sk->sk_data_ready(). 3) If application is using poll(), tcp_poll() will then use tcp_stream_is_readable() and decide the socket receive queue is not yet filled, so nothing will happen. Even when sender retransmits packets, phases 2) & 3) repeat and flow is effectively frozen, until memory pressure is off. Fix is to consider tcp_under_memory_pressure() to take care of global memory pressure or memcg pressure. Fixes: 24adbc1676af ("tcp: fix SO_RCVLOWAT hangs with fat skbs") Signed-off-by: Eric Dumazet Reported-by: Arjun Roy Suggested-by: Wei Wang Reviewed-by: Wei Wang Signed-off-by: David S. Miller Signed-off-by: Sasha Levin --- include/net/tcp.h | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/include/net/tcp.h b/include/net/tcp.h index 37b51456784f8..b914959cd2c67 100644 --- a/include/net/tcp.h +++ b/include/net/tcp.h @@ -1409,8 +1409,13 @@ static inline int tcp_full_space(const struct sock *sk) */ static inline bool tcp_rmem_pressure(const struct sock *sk) { - int rcvbuf = READ_ONCE(sk->sk_rcvbuf); - int threshold = rcvbuf - (rcvbuf >> 3); + int rcvbuf, threshold; + + if (tcp_under_memory_pressure(sk)) + return true; + + rcvbuf = READ_ONCE(sk->sk_rcvbuf); + threshold = rcvbuf - (rcvbuf >> 3); return atomic_read(&sk->sk_rmem_alloc) > threshold; } -- 2.27.0