From nobody Tue May 5 12:31:06 2026 Received: from mail-pf1-f178.google.com (mail-pf1-f178.google.com [209.85.210.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 8AE902DFF04 for ; Wed, 22 Apr 2026 12:09:59 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.178 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776859802; cv=none; b=T69bvly4Ig5mH3mZ00NITvtnoWqKgKz1ao4nU/R8177uLSf2DMUV8muG99QhUlSQVAPOmB7rSiIv2Kq46YKQjV/BYD5QeoilcKVyk1p5wWaNpEpLvY4r/ASgQuRqea0ncc8UuX3Kc0HUMLChEZzqczZy30G/XBRfYcfUWTgCK2c= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776859802; c=relaxed/simple; bh=hjsvYy51l4+d68+Ky+C/JI2f1kTJUYN+qBMx0/prB8M=; h=From:To:Cc:Subject:Date:Message-Id:MIME-Version; b=qc2NC1pO/ew4QLqQx4GDUMs1TgISd1oPfibM1nOv7G0sO8T839j8S+VjMkwVZTfJ9x0MvOhhSZOL9n66dLgncPXDYjdvpiy1EDCxaUg2wmlz9Ai1J6UxwIejSMMD0F5vHHiQnKi3i51sKv7H4pdeJceE8Pjcqh/9mV3P4e+PDJQ= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=YAW8g/Hg; arc=none smtp.client-ip=209.85.210.178 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="YAW8g/Hg" Received: by mail-pf1-f178.google.com with SMTP id d2e1a72fcca58-82fbdd60b64so2041510b3a.3 for ; Wed, 22 Apr 2026 05:09:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1776859799; x=1777464599; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=NebLMnO65OtCJ9kTmTFrhiV9D6tfIFz2CrdNbRxmY7A=; b=YAW8g/HgKU5Cd2daADXGyw2RYXgjloJ56nAgLpNmEVoliVjzt+3j70wqU4AhqP+bEQ lB9Q4Io8E+oSWhll0Yd1u8ATHbUFLkfKkZpKiLCZ9+1MCTtIKghCZeioTU9Kx8i87sTz 3IjiP1g59fp/3JudOUIFUhKn9PwBikLi21GrUF2Ruc5vnAfBHZ5euDGmVlJS/tbCCrgy at7tb4vE4fgUaT5OLPDnMX4dH40ORqKM/zResc1LovT9em6FmHJ6HMGmApN/FbL6nVfO XDFmDtD1oN0+NU+qwJURVqWA3h0wtZ9ESuQ7/roDzXJ5jFYGfgQocqi5dQKpX74bAlK0 FCvg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1776859799; x=1777464599; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=NebLMnO65OtCJ9kTmTFrhiV9D6tfIFz2CrdNbRxmY7A=; b=Qr1OqSHJ87wzGE2DG3DkrDku2LGq3MAdzGDWfgIxf/OZUhr1QTGJ6rMtE2unXs+VUX w98jxT2h4DNxDDT5aIw50TyRkaHcbSNN9cYnsuAZor7iQ+3gFQ8UmTKvnfJVPsiOXoR4 EFC4TUz+x5z/R7/+K7nfpcmtufq0pgv0mnRZiGZG0nPPfHFTu/iN4LzSr0lQ9VqwzPgx BHFwdbweGNCSexkQqHeWkK3LqviMYfn79nypvuc+Ou4ACKsPzqLk27wrcMK8TN7Gc7dv FrN1ELGh2aFiEiXS0QLP8TpWubnmYABdkQMbNLJWwKACp8AJ12oMXWOpn5X6+9sSa1Yp bdLQ== X-Forwarded-Encrypted: i=1; AFNElJ845BnnpCd1JnkkAi4DQQKwhlWUrNuIJwLgxktF39cASrTiaqyqpQq82Wt8bz0G8REw8XmyH3Fj66OgSw0=@vger.kernel.org X-Gm-Message-State: AOJu0YylnzVPyYOKOrxDYcjRUOokVd98UmUdbCS2Pok3821cPoDb3jJh 6hamdgWAuslr4m2NKiOulvX6TmrwmV6+py05Ddmj7gJv4o8upJsZ7FnI X-Gm-Gg: AeBDievCj7JSSHFLyWZVMpPWY+uMHuKUcrBRQ8rDlG7QfvfstpPPY0GyxwrA/Y7JBTS LluhIGzuaF0JzstfHMzT6zkjhaN3HVeXeOwzhh7VCXdcFDkoyIcwwTluMEK/EtUH2BFZrCdQ4KT nxMBcJszDFZyW1+bl3gJylZ7W1aiBVM9/NBj2GUfBnE/UUoCfR42Kn2/K9NQdhU94RZZuw6tyjA 8CqKTcZ6ddahx5PBvYni3dxWYMDNSrx5ucouzcjQmZ5zPp0pQ/KWeVXpQQBTWeB1FoC4aZF14+H VTBfRsD5nUgDL4MmQw+zGQ/QOhSFdpE5oNYGFxBlGNBfDi8iA0PwNorN0ssv3uwSPEeS9ZrY3/h zjKai9bNljcus9ClB/YN2viqQO8uthvK5ZcqJcDnSgnFYgFfK/BddlGB2a/zNXxJg8LjpDUbjM4 XEMj9ijHtqMap3o0IFcqugcion89wSWSw= X-Received: by 2002:a05:6a00:3e16:b0:82f:5571:1a8d with SMTP id d2e1a72fcca58-82f8c8308e0mr23715240b3a.2.1776859798571; Wed, 22 Apr 2026 05:09:58 -0700 (PDT) Received: from localhost ([223.185.43.14]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-82f8e9fcea9sm21196745b3a.23.2026.04.22.05.09.57 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 22 Apr 2026 05:09:58 -0700 (PDT) From: Shardul Bankar X-Google-Original-From: Shardul Bankar To: matttbe@kernel.org, martineau@kernel.org Cc: geliang@kernel.org, pabeni@redhat.com, davem@davemloft.net, edumazet@google.com, kuba@kernel.org, horms@kernel.org, netdev@vger.kernel.org, mptcp@lists.linux.dev, linux-kernel@vger.kernel.org, janak@mpiric.us, kalpan.jani@mpiricsoftware.com, shardulsb08@gmail.com, Shardul Bankar Subject: [PATCH] mptcp: do not drop partial packets Date: Wed, 22 Apr 2026 17:39:54 +0530 Message-Id: <20260422120954.8877-1-shardul.b@mpiricsoftware.com> X-Mailer: git-send-email 2.34.1 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" When a packet arrives with map_seq < ack_seq < end_seq, the beginning of the packet has already been acknowledged but the end contains new data. Currently the entire packet is dropped as "old data," forcing the sender to retransmit. Instead, skip the already-acked bytes by adjusting the skb offset and enqueue only the new portion. Update bytes_received and ack_seq to reflect the new data consumed. A previous attempt at this fix (commit 1d2ce718811a ("mptcp: do not drop partial packets"), reverted in commit bf39160c4218 ("Revert "mptcp: do not drop partial packets"")) also added a zero-window check and changed rcv_wnd_sent initialization, which caused test regressions. This version addresses only the partial packet handling without modifying receive window accounting. Fixes: ab174ad8ef76 ("mptcp: move ooo skbs into msk out of order queue.") Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/600 Signed-off-by: Shardul Bankar --- net/mptcp/protocol.c | 25 ++++++++++++++++++++----- 1 file changed, 20 insertions(+), 5 deletions(-) diff --git a/net/mptcp/protocol.c b/net/mptcp/protocol.c index 614c3f583ca0..6858e6e283e3 100644 --- a/net/mptcp/protocol.c +++ b/net/mptcp/protocol.c @@ -397,12 +397,27 @@ static bool __mptcp_move_skb(struct sock *sk, struct = sk_buff *skb) return false; } =20 - /* old data, keep it simple and drop the whole pkt, sender - * will retransmit as needed, if needed. + /* Completely old data? */ + if (!after64(MPTCP_SKB_CB(skb)->end_seq, msk->ack_seq)) { + MPTCP_INC_STATS(sock_net(sk), MPTCP_MIB_DUPDATA); + mptcp_drop(sk, skb); + return false; + } + + /* Partial packet: map_seq < ack_seq < end_seq. + * Skip the already-acked bytes and enqueue the new data. */ - MPTCP_INC_STATS(sock_net(sk), MPTCP_MIB_DUPDATA); - mptcp_drop(sk, skb); - return false; + copy_len =3D MPTCP_SKB_CB(skb)->end_seq - msk->ack_seq; + MPTCP_SKB_CB(skb)->offset +=3D msk->ack_seq - MPTCP_SKB_CB(skb)->map_seq; + msk->bytes_received +=3D copy_len; + WRITE_ONCE(msk->ack_seq, msk->ack_seq + copy_len); + tail =3D skb_peek_tail(&sk->sk_receive_queue); + if (tail && mptcp_try_coalesce(sk, tail, skb)) + return true; + + skb_set_owner_r(skb, sk); + __skb_queue_tail(&sk->sk_receive_queue, skb); + return true; } =20 static void mptcp_stop_rtx_timer(struct sock *sk) --=20 2.34.1