From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f181.google.com (mail-pl1-f181.google.com [209.85.214.181]) (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 7C8333ED5D6 for ; Wed, 22 Apr 2026 14:39:37 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.181 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776868779; cv=none; b=bnEnFpH4Yry9WSJoSPSQG8Zm83yStpJAKdYrOi5FHkuNu/PlrVV/3NvK5Pnb7XB8Qckz4vah24nzrCBGWv48jaQ3WXxqoZD4DubzeUQ8Ee455d649OG4lKFxW4Y4gC5hwHY+eKXw8m+HctFN/HGh1g5nvZ8I/j199+wq7iHFANU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776868779; c=relaxed/simple; bh=iZ9suLIuBUoCeCnetfnZ7mtmyUYxmiPfo0+beK82tOo=; h=From:To:Cc:Subject:Date:Message-Id:MIME-Version; b=QBbEv/bYcgu2yxFsAuUegqGHDxzIxsOK7/mUTJ8NRoutWNJjM6K17KCXDQDPAAYYoGfnDLTYhASN2KlYnhDYqbbKlOA5/IAIF3xE6rbTPBkqsV6J8y5II8xnU4m/pzC22qNrRTfDAK6vj4sNwN0jSPYDtUTTc456SVUiRZAL5Y0= 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=D1+UzRBL; arc=none smtp.client-ip=209.85.214.181 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="D1+UzRBL" Received: by mail-pl1-f181.google.com with SMTP id d9443c01a7336-2b2d3a9e149so30711275ad.1 for ; Wed, 22 Apr 2026 07:39:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1776868777; x=1777473577; 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=v1HO4kkoe4n1JrCENVUM3crOySJ+rOzuctiq2bNthFo=; b=D1+UzRBL9L4vibylI3+D+HQl1gnmwiDxYArvfT4hppriIyGv73AQrBmCqpa2LHj05S aSTq1GfmeWa7p0zXC3mJQx1tiKcCtPePmMLe+RDpwBUhmAZd01Kpskup11HbNXBdc2ZD mLt3v3uNY8Oo4c9K9lx4gu+kQMzWXpWLFP4mu1OcMisz6DkKiHKnk3wvezXQtZ6IclEB FjeMle2siDUIOayg28e//HnRBq+W5Xga23OYI50oB220nNifHQ6O3JMmzM+IZDQ+dX/n +qGa+Q32oB8i/xBd7B58KzIOSghHVgOSDF4NCqhUoPZnACP+HBEJZ5judoNYHgiOQh0S PoGw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1776868777; x=1777473577; 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=v1HO4kkoe4n1JrCENVUM3crOySJ+rOzuctiq2bNthFo=; b=llCzdVf8pAwvxJzisVHXeowz6aWkTJqpUqXEAWtsIiS2KWnX5kLUJKBeSHy+3K+0nS wQrdqf1KXh1IF9Ls/dkpgFwqvFuM28Ql4RjPwv+LNkVkfaS/chbjyCvYHXCsq6JRh7E7 witqq9BqtpADevyiZqBAsSpqPKzbRZulRnQxx3WxOPlw8KT/lUzOWn2RzINiDfsSs6Vu 7NBft+0FBbY0ZRmsZdJbV4fsvb5d34XAKASeL8k81z6wKvaAmV4eFhvvRID6JUvBtIth cE/wQLeGjcbMA5Cj1UCBQNui+uOg8qaLdqbmwrZ9RbROCRcCu9zc2QSjRk5no/ybjIgF y/gQ== X-Forwarded-Encrypted: i=1; AFNElJ9VlhPDnxIprcE5kBTnpheIodpNYL+pozLvqiKpdk14Qbn71K4RGwf3ev30em/smne9AWrMPhxjMQDpQnE=@vger.kernel.org X-Gm-Message-State: AOJu0YxcJSVg/U2mFJNNvEeObHkvjY2O8e0jWiWafIrzbILWP8hvLRDO h2kbfFZs/g8GA6vbjmYCskM0i3bfW7i5EOn353FofFKqTE56OX1RbkiB X-Gm-Gg: AeBDietSlh6G+mvQfAkz1XGnCapg9m2In9Pajd/mdhjrZpkp+YyxF6pSTN+ZFkbCZl+ oFgUlicC8pEsF7DPYlDxDyNfk77QVnEWbgGWRoUEAt7k8xlIuf0Mlew2r/U91mE2K/pNFruN6+x 2XkPJPsGlYV6/D+drSXNEH+O2TnlrM1JHZs8RmdvhyRkOPxs6nEXVdL8t55ZLhFnLyVnB6bhBsz U+bqLA5R5n8fjTUgGlKTrlVNaQqPqbcAJ204qDyK2YjoB8mriUx55g+b3L6/G09EiE+k91FhGqs KH6Lywmlk79wl+f6GCVC8QT9GdFfyJdeEueTIbrjuiRFdG5dfRSDM1g0cLBUVkbiUlVmREpamtw gsBZEMojimcRvFxEd7ADumW6SM8nirR5UDtQSe8n8WcQuneG03x15GEzasvylblQaLYyYfcA72k D2mqo7hkUrUFb1OOzeP3idJyvAAJo/zy0X1hDpMXKj8w== X-Received: by 2002:a17:902:ef10:b0:2b0:ac1e:9730 with SMTP id d9443c01a7336-2b5f9e931b5mr183257505ad.14.1776868776613; Wed, 22 Apr 2026 07:39:36 -0700 (PDT) Received: from localhost ([223.185.43.14]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2b5faa507cbsm173588135ad.37.2026.04.22.07.39.35 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 22 Apr 2026 07:39:35 -0700 (PDT) From: Shardul Bankar X-Google-Original-From: Shardul Bankar To: pabeni@redhat.com, matttbe@kernel.org, martineau@kernel.org Cc: geliang@kernel.org, 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 v2] mptcp: do not drop partial packets Date: Wed, 22 Apr 2026 20:09:31 +0530 Message-Id: <20260422143931.43281-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: 8bit 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 --- v2: Drop the mptcp_try_coalesce() attempt for partial packets, since non-zero offset always prevents coalescing (Paolo). net/mptcp/protocol.c | 22 +++++++++++++++++----- 1 file changed, 17 insertions(+), 5 deletions(-) diff --git a/net/mptcp/protocol.c b/net/mptcp/protocol.c index 614c3f583ca0..73ec6563ab2b 100644 --- a/net/mptcp/protocol.c +++ b/net/mptcp/protocol.c @@ -397,12 +397,24 @@ static bool __mptcp_move_skb(struct sock *sk, struct sk_buff *skb) return false; } - /* 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 = MPTCP_SKB_CB(skb)->end_seq - msk->ack_seq; + MPTCP_SKB_CB(skb)->offset += msk->ack_seq - MPTCP_SKB_CB(skb)->map_seq; + msk->bytes_received += copy_len; + WRITE_ONCE(msk->ack_seq, msk->ack_seq + copy_len); + + skb_set_owner_r(skb, sk); + __skb_queue_tail(&sk->sk_receive_queue, skb); + return true; } static void mptcp_stop_rtx_timer(struct sock *sk) -- 2.34.1