From nobody Thu Oct 31 00:20:55 2024 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id B39901AC437; Wed, 31 Jul 2024 10:10:38 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1722420638; cv=none; b=qHvlfVhRF4MG/T2dQY5UI1xN9aqYrCWJy29eAsvmWTggMKtdALaAnsejTSy82ASNmtsQVZeSodSJKlOhlC2L8TYFWlM7U/1jVAld7UGtcaykqgXUqXCT0eHKqyGazOtKZQYqInCX272rBuo0+p79g5KdGGAE+EwrijKunNrCN2o= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1722420638; c=relaxed/simple; bh=H8Dt8TRfu+FKsLww2oDHhCRoGlO5idEYzWV180422Jw=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=rAWgtFfjDpDKX4UigVyj32Kh0Xw3FJ/Z6hNLVce7rGt+kk1xwhlibVAiL1rzp9wsT4JrURyEXrXVQMMSLfRbSQ4YQQX7kbsDwA4ks4oal+mOCLzdcicys90tL6XID/Z79fUn0WOuggZyABiEuGEkFtwdc4tTj06FJJ+OyHNJHO4= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=ZHXi8JZm; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="ZHXi8JZm" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 01FE3C4AF0E; Wed, 31 Jul 2024 10:10:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1722420638; bh=H8Dt8TRfu+FKsLww2oDHhCRoGlO5idEYzWV180422Jw=; h=From:Date:Subject:References:In-Reply-To:To:Cc:From; b=ZHXi8JZmYg/E1xsKvJZ/Ati9mTTFqY5Z48J2Ng5ynET3AuDAhDHJnHd0TRl/djgVi NssnY5CI0qpvho14w5OSkQVZxy9K4d7A8Ky9W/U4RdJ4mtbEyGJbqRS5P0NdiNJHxP vGgRjslj17M+rFDs4c/pO8sZ//vUuPWQT7pRoxu9r09ILt6oFUpmKG/DaUNTXDd1zl oR0MWtF05+B/jc4Pmrdnzy5o2UrZTJ0ZiwyCu9j3WNex2EvG1mlZEHLD+p/6yBs8g7 Aaypo7iGl7DYzX+SNj3EZr9pi79A8gu5kJPkpqVu/qLUWDeCjgrQYZliO/py4Cnj9h Vxty4d4zGGWVQ== From: "Matthieu Baerts (NGI0)" Date: Wed, 31 Jul 2024 12:10:14 +0200 Subject: [PATCH net 1/2] mptcp: fix bad RCVPRUNED mib accounting Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <20240731-upstream-net-20240731-mptcp-dup-data-v1-1-bde833fa628a@kernel.org> References: <20240731-upstream-net-20240731-mptcp-dup-data-v1-0-bde833fa628a@kernel.org> In-Reply-To: <20240731-upstream-net-20240731-mptcp-dup-data-v1-0-bde833fa628a@kernel.org> To: mptcp@lists.linux.dev, Mat Martineau , Geliang Tang , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org, "Matthieu Baerts (NGI0)" , stable@vger.kernel.org X-Mailer: b4 0.14.1 X-Developer-Signature: v=1; a=openpgp-sha256; l=1600; i=matttbe@kernel.org; h=from:subject:message-id; bh=B/IpD4eT5lsmU2JoZeqN31jRGBuOWnvRkoQrDPft8yw=; b=owEBbQKS/ZANAwAIAfa3gk9CaaBzAcsmYgBmqg2YhQwvfFDP40KU2RFMHcfK7PKTzl1i2eapZ O07AQtI+Q2JAjMEAAEIAB0WIQToy4X3aHcFem4n93r2t4JPQmmgcwUCZqoNmAAKCRD2t4JPQmmg cynOD/9Dl/Nb3D4GsnwPqGjv5vj164TQMI0CPsqRsfooaNRsE8jRLWflKslWfQrlesNV+oFDnbO DGL04ppWvM4ydxnfVneZAXJWl+eNyj4461s0GnFWPQzqaEE/3rncw/AAaVCTpoliHzZJUbkrrp+ T0HD9qYHXqCWeVnfVhdPa7Tzjeji7570dosC56mvT1aLhcAP9tGdpkF9fpigaEDOVfeVPLZoTwt EMNiorNor6ZczQXRpx5h/wrxNoZpwEEWWhJr7YjBXyQLcK7xYSqnMWOVXGj+IDIFv4RjFWB9G5s MMvAIgq/VW1hWihYvNHGqhqKVOmyc0UM/5u+3QS0XMkQwigh419cWgKAbam1kribE3f0kqoBol5 LeOiuYbERa3Qn6avpek0ETp7jbrcZd6VbZ5lcZiUYPUjgCdSuPxdBf3LYz41eR5jRZLxC0/EVtC EiHi60uCIIUQWiwQoQ24znot3MGuRvYHDT0hkGl1Vq3h18f9brHM2sEGHwDEkQjsF04m+LYDyHY OwG7gXZrhVEcodOvhQN18jEbiu9u8d18W4eRcrLnlpQJ/W07WgTH5EYFH4fdRybgaB+5oG/PrAD YJALASt3fndTNAAWQqOOCF6OnrzmnC7YfbJdZqtHZ59bcqs5C5uFQuHq0HUH5bcLJKDIdVDyOfA 8AviwiuMPslFF2g== X-Developer-Key: i=matttbe@kernel.org; a=openpgp; fpr=E8CB85F76877057A6E27F77AF6B7824F4269A073 From: Paolo Abeni Since its introduction, the mentioned MIB accounted for the wrong event: wake-up being skipped as not-needed on some edge condition instead of incoming skb being dropped after landing in the (subflow) receive queue. Move the increment in the correct location. Fixes: ce599c516386 ("mptcp: properly account bulk freed memory") Cc: stable@vger.kernel.org Signed-off-by: Paolo Abeni Reviewed-by: Mat Martineau Signed-off-by: Matthieu Baerts (NGI0) --- net/mptcp/protocol.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/net/mptcp/protocol.c b/net/mptcp/protocol.c index a2fc54ed68c0..0d536b183a6c 100644 --- a/net/mptcp/protocol.c +++ b/net/mptcp/protocol.c @@ -350,8 +350,10 @@ static bool __mptcp_move_skb(struct mptcp_sock *msk, s= truct sock *ssk, skb_orphan(skb); =20 /* try to fetch required memory from subflow */ - if (!mptcp_rmem_schedule(sk, ssk, skb->truesize)) + if (!mptcp_rmem_schedule(sk, ssk, skb->truesize)) { + MPTCP_INC_STATS(sock_net(sk), MPTCP_MIB_RCVPRUNED); goto drop; + } =20 has_rxtstamp =3D TCP_SKB_CB(skb)->has_rxtstamp; =20 @@ -844,10 +846,8 @@ void mptcp_data_ready(struct sock *sk, struct sock *ss= k) sk_rbuf =3D ssk_rbuf; =20 /* over limit? can't append more skbs to msk, Also, no need to wake-up*/ - if (__mptcp_rmem(sk) > sk_rbuf) { - MPTCP_INC_STATS(sock_net(sk), MPTCP_MIB_RCVPRUNED); + if (__mptcp_rmem(sk) > sk_rbuf) return; - } =20 /* Wake-up the reader only for in-sequence data */ mptcp_data_lock(sk); --=20 2.45.2