Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp3527507pxb; Mon, 1 Mar 2021 12:21:28 -0800 (PST) X-Google-Smtp-Source: ABdhPJw+Tnc/7htVyAouLak4W0OzsE1KsFDhYZ3X8HGUqvvzcjvAVtW8VgzScwUwNZ7fcvhqeumt X-Received: by 2002:a17:906:9501:: with SMTP id u1mr8218540ejx.324.1614630087916; Mon, 01 Mar 2021 12:21:27 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1614630087; cv=none; d=google.com; s=arc-20160816; b=w4ILdQ333ihb4+XJLlFhF2tu1aNnuB4igSxLT75tzMCsVx1MRQ4amzj03/BWD/tsAF WAebtVdKR7Gc2knDNRJFynAXrBWsxLQ65Pj1NXAClucJCUFsde2XS1jkUDNfUMrW9Vz9 /yqYpvDlY7gwg5uHKw0KB+ic2s/WKpuHJtYYFWXeYnL9LxKW8IqM5luzJoS6HeZCf01R CT8m6jV70ev87ZirH7M+N1WV+NRG7FwPIEuR/rTp07Rt/W/Wo2HxKV/e5cPwejNvmH4X FBbsAtJX3tW7xMfpBzaTAHIuRjziy5FDKSaK9e2Di6etEsa8PZvfDIcxACsfY8gQY0I7 lR8w== 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=7FTXBYib7UA7N4+ITwqGFRLxww/h4BUvGk91Z9xU/Zc=; b=P7ml+oGzDPnVN+i6tch054UF3Te2bt3k4Zn/bu4pNHVUkghcPNaxLEnL9yYHxVAg+t OaQ7u2dy1Mul/shrJAN43JYubD0zFiUczNBArWU9Wrd5gz0jZ6XI0ZIZeqylc7jGyTDg Bjfr8Dia4nQlglfJ9mhazrUTFnsw9u1+C3ORO9fP9Hz6epbyF3pgvji3Ajus3VXI1Hzh EeOaIzZUTZnFTrPsviPtQxOeGUCYETD9wm8x27u8y3X/HUMf+Yw2zk/xQuizIc0McDpU k5oeBkagza7I3gZEg3sg3o1Ah7rfHUVLM7Zm4qBfAOi4Kmhxkr26znInfqN/3xifp52D 8fIg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=ckyPDL4G; 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 s19si9682539edc.275.2021.03.01.12.21.05; Mon, 01 Mar 2021 12:21:27 -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=ckyPDL4G; 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 S243230AbhCAUTA (ORCPT + 99 others); Mon, 1 Mar 2021 15:19:00 -0500 Received: from mail.kernel.org ([198.145.29.99]:36106 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237124AbhCAREu (ORCPT ); Mon, 1 Mar 2021 12:04:50 -0500 Received: by mail.kernel.org (Postfix) with ESMTPSA id 35A8764FF5; Mon, 1 Mar 2021 16:39:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1614616778; bh=QD2KpXmYg5cyS63tI92aYe2dlM2Qq4Rj0vgiAwW9AR8=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=ckyPDL4GxAz1rA3fhCz6y32ACh3cBaNJpYFz+H9ihSnLsX/K0ISPr5T/D7GQXZj5V D3lNFJU9lC5AILhGDYqHbQ3PD7ZYm3msLbmvFiHSFwTK27mEeA3txY2RCWpgPBJqvk 4b2+w2EWaklcjV5uos9TCDnT2PEVB2lRVOREIgsE= 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 4.19 063/247] tcp: fix SO_RCVLOWAT related hangs under mem pressure Date: Mon, 1 Mar 2021 17:11:23 +0100 Message-Id: <20210301161034.753238513@linuxfoundation.org> X-Mailer: git-send-email 2.30.1 In-Reply-To: <20210301161031.684018251@linuxfoundation.org> References: <20210301161031.684018251@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 afbe1d3991f21..4fe3ab47b4803 100644 --- a/include/net/tcp.h +++ b/include/net/tcp.h @@ -1380,8 +1380,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