From: Octavian Purdila <tavip@google.com>
To: Eric Dumazet <edumazet@kernel.org>,
Neal Cardwell <ncardwell@google.com>,
Kuniyuki Iwashima <kuniyu@google.com>,
"David S . Miller" <davem@davemloft.net>,
David Ahern <dsahern@kernel.org>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>
Cc: Simon Horman <horms@kernel.org>,
Shakeel Butt <shakeel.butt@linux.dev>,
Willem de Bruijn <willemb@google.com>,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
Octavian Purdila <tavip@google.com>
Subject: [PATCH net v5] tcp: do not let tcp_collapse() drive sk_forward_alloc negative
Date: Wed, 28 Oct 2026 19:08:20 +0000 [thread overview]
Message-ID: <20261028190820.2917252-1-tavip@google.com> (raw)
From: Eric Dumazet <edumazet@kernel.org>
tcp_collapse() charges each newly allocated skb with skb_set_owner_r()
before the skbs it replaces are freed, without scheduling memory first.
Since sk_mem_uncharge() reclaims eagerly, sk->sk_forward_alloc has no
cushion and can become negative. This can be durable when the collapsed
skbs had a high payload/truesize ratio or were partially read, because
the new skbs can have a bigger total truesize than the old ones.
A negative sk_forward_alloc then confuses tcp_wmem_schedule(), which
can return a negative length to tcp_sendmsg_locked(), triggering
a WARN_ON_ONCE(bytes > INT_MAX) in check_copy_size().
Call sk_forced_mem_schedule() before charging nskb.
Fixes: 4890b686f408 ("net: keep sk->sk_forward_alloc as small as possible")
Signed-off-by: Eric Dumazet <edumazet@kernel.org>
Reviewed-by: Kuniyuki Iwashima <kuniyu@google.com>
Signed-off-by: Octavian Purdila <tavip@google.com>
---
Changes in v5:
- Replace clamping in tcp_wmem_schedule() with Eric's patch calling
sk_forced_mem_schedule(sk, nskb->truesize) in tcp_collapse() so
sk_forward_alloc cannot become negative in the first place and the TX
fast path is untouched.
- Defer the packetdrill selftest to net-next alongside the upcoming
broader tcp_collapse() improvements.
- Link to v4: https://lore.kernel.org/netdev/20261026032216.1145201-1-tavip@google.com/
net/ipv4/tcp_input.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index 99baf14afdfd8..24d5f016a4eb6 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -5846,6 +5846,10 @@ tcp_collapse(struct sock *sk, struct sk_buff_head *list, struct rb_root *root,
__skb_queue_before(list, skb, nskb);
else
__skb_queue_tail(&tmp, nskb); /* defer rbtree insertion */
+ /* nskb is charged before the skbs it replaces are freed.
+ * Make sure sk->sk_forward_alloc can not become negative.
+ */
+ sk_forced_mem_schedule(sk, nskb->truesize);
skb_set_owner_r(nskb, sk);
mptcp_skb_ext_move(nskb, skb);
--
2.56.0.313.g2479322e68-goog
next reply other threads:[~2026-10-28 19:08 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-28 19:08 Octavian Purdila [this message]
2026-10-28 19:11 ` [PATCH net v5] tcp: do not let tcp_collapse() drive sk_forward_alloc negative netdev-bot+sinfo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20261028190820.2917252-1-tavip@google.com \
--to=tavip@google.com \
--cc=davem@davemloft.net \
--cc=dsahern@kernel.org \
--cc=edumazet@kernel.org \
--cc=horms@kernel.org \
--cc=kuba@kernel.org \
--cc=kuniyu@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=ncardwell@google.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=shakeel.butt@linux.dev \
--cc=willemb@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.