From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.remote-ip=209.85.210.197 ARC-Seal: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; cv=none; t=1793068135; b=3ABVpzoPvCbzYxXrGqx8lNPC7cTZjNebgfFluTRLH+fulN6FK2CK0Fp1JRE3zReoJ3Ga zeR58rs6bBCgM3ukuikVU99lZeiniRBHBQzTWxUAmiboW4n9jRSUXtGma2fXP594NpBaa Q5lIAOqwyzFRt/drLaZJGYZJ2wbWDPUc8cwzyXfSQkB2tvuxi0+W5XMylNTspHSwwqz4y B6VeQwrZTRYzUz+5f+Tyf6eHC1NIgYcOJo3tp6jy4RbWP0buHqGcNthzymf4wYk5tgH4d R6LrBSAK4ukoCXD9xDfe317UQiTDAFq9Y6mavcuFF05bPrE1TJjfG/Sd0SJhAztt2dQ== ARC-Message-Signature: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; c=relaxed/relaxed; t=1793068135; h=DMARC-Filter:Received:DKIM-Signature:X-Google-DKIM-Signature: X-Forwarded-Encrypted:X-Gm-Message-State:X-Received:Date:In-Reply-To: Mime-Version:References:Message-ID:Subject:From:To:Cc:Content-Type: Content-Transfer-Encoding; bh=0DKYkKim1zCQPtEbSstx8AMdlP0KYJRU77N3GxfZjCQ=; b=bYn3fdtreeHEfVyd40VnV9ANjP/XoE5s5jo9KQ+A83iik+fiDVNnCe19e8WdeULHCEn9 3KtlAgqW9+J8+4OyiMuulHR93D06I2PBo+2s3NnELUFy3vScOZ/T94zhH9Nb/vFsO/z9I Z1cboVE7pQb1lrkEY4+PNCdNA5e4UIRfOJGqzK/22CZIMgHkbkrrKsDfEadJfetd82svA J3FsgOeDUft5mYENtuwH8YFpyifpSCOp4qqcE7+Kc73MX1FGd+vB/p+GK+mtdvOuDPPUI ZQ+vPprmisRtDB6I+MrYqbKONsTyXRO72rAS84SYBt3jXpX1/qZOtBQWycpqETLqQ7w== ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass header.from=google.com; spf=pass smtp.mailfrom=flex--kuniyu.bounces.google.com; dkim=pass header.d=google.com header.i=@google.com header.a=rsa-sha256 header.s=20251104 header.b=Qh9HjegA; arc=none smtp.remote-ip=209.85.210.197 Received: from mail-pf1-f197.google.com (mail-pf1-f197.google.com [209.85.210.197]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id A52CA606A31A for ; Tue, 27 Oct 2026 02:28:54 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.2 smtp.subspace.kernel.org A52CA606A31A Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=flex--kuniyu.bounces.google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key, unprotected) header.d=google.com header.i=@google.com header.a=rsa-sha256 header.s=20251104 header.b=Qh9HjegA Received: by mail-pf1-f197.google.com with SMTP id d2e1a72fcca58-88c768885b4so6439549b3a.0 for ; Mon, 26 Oct 2026 19:28:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1793068134; x=1793672934; darn=vger.kernel.org; h=content-transfer-encoding:content-type:cc:to:from:subject :message-id:references:mime-version:in-reply-to:date:from:to:cc :subject:date:message-id:reply-to:content-type; bh=0DKYkKim1zCQPtEbSstx8AMdlP0KYJRU77N3GxfZjCQ=; b=Qh9HjegAyEtpn6PG1OPFrqSgqRSnAT+UgBbUz6YO/svCJETYoLjJh3Xbyh6i3MFnHo 0mT1hXeXE6AoQERRJDjzqP6egkXGq+qGL/pjaQpKzcjYf71ePPRxVT4Agph23mcdKRMe hGwSatkqZjIz8eypALgUtTYx6MTXjWuJ6kNks3g+hL2FODNfeVDDDsChdJm47LfTVP7X BE6C7QiHgucjS8AF3PCPSnkfeLnKR9A5a5oKMxfAD09nTrinGvadnqVPN7wD80lzAyJk cdccKhOiORVJG4FjBCfmhllHamFSCPzAQoMJZVdRjkoPT+nqIdyV3D4Nv5LNNbL7XJ3/ c6Sg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1793068134; x=1793672934; h=content-transfer-encoding:content-type:cc:to:from:subject :message-id:references:mime-version:in-reply-to:date :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=0DKYkKim1zCQPtEbSstx8AMdlP0KYJRU77N3GxfZjCQ=; b=lGLQzr4UbPt26I1NdbHrezmlGB2fwjBAajXjfspBNoMdjcmPSENQ7/WN9ZBM+8KIvU HuYrjHXYL14tOwgbyYaOsJytuNULYlIzzVMiM4oqoUUe856u6obZU/JPQizDowwwY7NZ e/yIshbmMBlfOk2ANNdnPoUPR+Z9oQoM5SDTOp0sE4Q6T8UHXWME6vzSjeMwc4w2Q5XU dxiyCfikHkpP8lYycvFD2YybM5C4A6eoUyZEXPK/YpnsC5lxldjLcMBF7ISi4e9pA84s Z/msD+umcEtob+SfE5UJ6fW2/oHk6v/KFsORzGfAGLD46u81otRjkVCX05iSYMLmEuy8 N80Q== X-Forwarded-Encrypted: i=1; AKwUvBxzCERRlCE1iGTwQyWTOYpNt92/Fh7ra0a47hfBX6A2+KAlC+W3aWkMsDaX/ebuRrMHbXcg6Mg=@vger.kernel.org X-Gm-Message-State: AFq9FYLy4kRE0tAXQAIWStLdpYXdI/1RwEuSDZ7CO3T2GdquR6Jz9Y78 dNsC3edR0lJoWCD1l+wExFj0gyJcADvr66h+y+iudKqpanpRGShZWnoeeouaX1HLqCcgZtIkd6K 2im5h3g== X-Received: from pfak4.prod.google.com ([2002:aa7:92c4:0:b0:887:8dda:c9e4]) (user=kuniyu job=prod-delivery.src-stubby-dispatcher) by 2002:a05:6a21:3f90:b0:3e2:8ca9:5c6c with SMTP id adf61e73a8af0-3e7bfbd65f6mr5850646637.20.1793068133781; Mon, 26 Oct 2026 19:28:53 -0700 (PDT) Date: Tue, 27 Oct 2026 02:28:53 +0000 In-Reply-To: X-Mailing-List: netdev@vger.kernel.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list Mime-Version: 1.0 References: <20261026032216.1145201-1-tavip@google.com> <20261026032216.1145201-2-tavip@google.com> Message-ID: Subject: Re: [PATCH net v4 1/2] tcp: clamp return value of tcp_wmem_schedule() to non-negative From: Kuniyuki Iwashima To: Eric Dumazet Cc: Octavian Purdila , Eric Dumazet , Neal Cardwell , "David S . Miller" , David Ahern , Jakub Kicinski , Paolo Abeni , Shuah Khan , Simon Horman , Willem de Bruijn , netdev@vger.kernel.org, linux-kselftest@vger.kernel.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Mon, 26 Oct 2026 13:06:56 +0100, Eric Dumazet wrote: > Le lun. 26 oct. 2026 =C3=A0 04:22, Octavian Purdila a = =C3=A9crit : > > > > When sk_wmem_schedule(sk, copy) fails under TCP memory pressure and > > sk->sk_wmem_queued already reaches or exceeds sysctl_tcp_wmem[0], > > tcp_wmem_schedule() returns min(copy, sk->sk_forward_alloc). > > > > However, sk->sk_forward_alloc is a signed int that can transiently > > become negative when tcp_collapse() re-packs partially read or high > > payload-to-truesize SKBs in the receive queue and charges newly > > allocated SKBs via sk_mem_charge() before freeing the original SKB. > > > > If tcp_wmem_schedule() returns a negative value, tcp_sendmsg_locked() > > passes that negative copy length to skb_copy_to_page_nocache() -> > > copy_from_iter_full() -> check_copy_size(), where it is converted to an > > unsigned size_t > INT_MAX, triggering a WARN_ON_ONCE(bytes > INT_MAX) > > in production and returning -EFAULT instead of waiting for memory or > > returning -EAGAIN: > > > > WARNING: CPU: 1 PID: 939331 at include/linux/thread_info.h:249 tcp_se= ndmsg+0x10c1/0x1530 > > Call Trace: > > > > __sys_sendmsg+0x292/0x490 > > do_syscall_64+0x88/0x340 > > entry_SYSCALL_64_after_hwframe+0x76/0x7e > > > > Clamp the return value of tcp_wmem_schedule() to [0, copy] so callers > > treat negative sk_forward_alloc as 0 available bytes. > > > > Fixes: 849b425cd091 ("tcp: fix possible freeze in tx path under memory = pressure") > > Assisted-by: LLM > > Reviewed-by: Kuniyuki Iwashima > > Reviewed-by: Eric Dumazet > > Signed-off-by: Octavian Purdila > > --- > > net/ipv4/tcp.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c > > index 87ef6d5cbfeba..0e062fcd94a6c 100644 > > --- a/net/ipv4/tcp.c > > +++ b/net/ipv4/tcp.c > > @@ -1037,7 +1037,7 @@ int tcp_wmem_schedule(struct sock *sk, int copy) > > left =3D READ_ONCE(sock_net(sk)->ipv4.sysctl_tcp_wmem[0]) - sk-= >sk_wmem_queued; > > if (left > 0) > > sk_forced_mem_schedule(sk, min(left, copy)); > > - return min(copy, sk->sk_forward_alloc); > > + return clamp(sk->sk_forward_alloc, 0, copy); > > } > > > > void tcp_free_fastopen_req(struct tcp_sock *tp) >=20 > I do wonder if the following fix could be better (no change in the fast p= ath) Exactly, this looks better too, we can avoid negative sk_forward_alloc and clamp(). The packetdrill will need to be adjusted as it triggers cgroup OOM with this approach, or we could defer the test to net-next too. >=20 > Before a complete fix in tcp_collapse() (in net-next) >=20 > tcp: do not let tcp_collapse() drive sk_forward_alloc negative >=20 > tcp_collapse() charges each newly allocated skb with skb_set_owner_r(= ) > before the skbs it replaces are freed, without scheduling memory firs= t. >=20 > Since sk_mem_uncharge() reclaims eagerly, sk->sk_forward_alloc has no > cushion and can become negative. This can be durable when the collaps= ed > skbs had a high payload/truesize ratio or were partially read, becaus= e > the new skbs can have a bigger total truesize than the old ones. >=20 > 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(). >=20 > Call sk_forced_mem_schedule() before charging nskb. >=20 > Fixes: 4890b686f408 ("net: keep sk->sk_forward_alloc as small as poss= ible") >=20 > diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c > index 1ddce9c4b7e8cf91bfd4f5361abec3925fe25046..e879bdfddf1abe2ced80b12ea= 8a40c1f7c958708 > 100644 > --- a/net/ipv4/tcp_input.c > +++ b/net/ipv4/tcp_input.c > @@ -5847,6 +5847,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);