Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp611696pxb; Wed, 3 Mar 2021 10:42:53 -0800 (PST) X-Google-Smtp-Source: ABdhPJxizr4wVHnjavDe/HHwYCorQ/jaQ7XipKThH6OBRV6Og8pHz06DA/GPqbjFVW3dc1aYomGS X-Received: by 2002:a17:906:4442:: with SMTP id i2mr209548ejp.41.1614796973215; Wed, 03 Mar 2021 10:42:53 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1614796973; cv=none; d=google.com; s=arc-20160816; b=RCqWxOKcAsy4+zNP9VfVekbB/FWCBbgLUPPqbcNpcqJVavXwlq4hZQtZ+dRZmAWiEb uFZPmqULxtlxfWpYt+tgQENVVyI5vvxz2gSKvx75FFyCmL6RDt7pa3hBs7qjcRxELwNS Pcj4unPqBHMbzsx1XH/axxY12XIYNBJhTRe+udS0lRgAcS9a+25tOd7DiWS5FdbX+2gO p/W59eSc/YU956G16iw4f6+z/Co98I2FZF1oD5HUJYjh6EuZeiQz8L22w8ESF1Tjx8zq ytr65NsuY0zIdegk3iX0wbIJ2bcULlfVCVNyd57MnTzNvRyYi/ikYKNFQZZ3OrqiIsUI gS1A== 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=WPNGnNcIarxYiqrYqm/7piBxvAFQybF6C8N4QacsCkU=; b=UKHKnTrz4NorVZKJvEvnGImD6BztlCyeON1cfdVvqT7D3X68L7/J3PQp3ZnSlzkE1D 2LabGxU5Rnz08MxJpywn08/904HYsY0084xao/GmCyONe1/nUTXWZJdNt2NUFvvnJzXR 4q4oO0ahW20FNM8Ei7nyLmdzEy4ElMJM0vvrTw2v9pfL8U3C07M6sNMnPni9owWEStCC gub1iVIE74ld/gBzmwaGfSzw8U4XLIbyMz0f+V6quHVTTkQP6wjoZnLhtNe/GXYFDumC vp3dm43EsTcjOavlgEeOshHRh+nTLG55+ks8M+OXfp9iEskeMjJ43DGagJgYK/KeArce bZfg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=vg5iihjb; 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 f16si7061783eds.608.2021.03.03.10.42.04; Wed, 03 Mar 2021 10:42:53 -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=vg5iihjb; 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 S1378272AbhCBBFL (ORCPT + 99 others); Mon, 1 Mar 2021 20:05:11 -0500 Received: from mail.kernel.org ([198.145.29.99]:34110 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235871AbhCAS65 (ORCPT ); Mon, 1 Mar 2021 13:58:57 -0500 Received: by mail.kernel.org (Postfix) with ESMTPSA id 2EB3B64F89; Mon, 1 Mar 2021 17:08:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1614618530; bh=Clq7V85fDlR6zkKLnia8E2GU8guNjCersNRh4+xRA1o=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=vg5iihjbm/++sGBwZfwTC5QaJy8MyLMJr8Nsc1UYgl6IQfLFfdh1Dek6uwPkXb+iW IN+ExT78SfAJfFneIO09q95LZM4KqWIfmg3E7HF+OilyD+HieGRX/eKxgqwVdm+nMU EpxDepLfowES6201QJ43P/ulL/IBm8emNNNw10SA= 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.10 120/663] tcp: fix SO_RCVLOWAT related hangs under mem pressure Date: Mon, 1 Mar 2021 17:06:08 +0100 Message-Id: <20210301161147.679996148@linuxfoundation.org> X-Mailer: git-send-email 2.30.1 In-Reply-To: <20210301161141.760350206@linuxfoundation.org> References: <20210301161141.760350206@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 fe9747ee70a6f..7d66c61d22c7d 100644 --- a/include/net/tcp.h +++ b/include/net/tcp.h @@ -1424,8 +1424,13 @@ void tcp_cleanup_rbuf(struct sock *sk, int copied); */ 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