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=SKx/VgYEO/xCFQVzBY71NqFH5FaHylAkNw24kAbX4wc/a2n+15jnOudVs9zwOUTFVWXg ug1+7+rUfhsKxvVMBPGTvrllWTaPZ2ZvEI7fUSSWHJY6JJib6qBfiCTTH1X2mXLshLOYZ IaY01daK4zos021KXWMojqWw+Y9EtrMnFVP72tDwBtagxN/+UD+EltF+L2Lx8a5q+kxGT lJEnetyalYvFIe5izxn1j6WnysK1QzJjg4vIgVdNDvWLj8yZzmpEzCHzN05FH+EyRNN4Z /ESjI1OGtxtC/w4wf7FVGydBCp0IgAga8QGNjmQtn6EmOPaoBeEtXJGLjAuZ7bKZ0ig== 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=QFRav+g/HZEqqgt5ouCf1t215S49s7Bs/ZyyBoZJOeB6xxmPw+KvHsXHwqbdh9b5n9Ze Vl1P8D8kDGYju76Tis0w6etOwlevlYJejXTaiOlJIfKQxkgeta7ixdKywFKJysHt4nLOY HJqMUFo/usX1mCOqubD+Y4ChBzEDy18m23G3sGUxlMiX24+BcuEGEnElYpTbsXfK4lRCK tEW8pyjl5n00CKNl6MBRJiUv0kEy3TZD453s7xg30R1BLpMAwcX9u0KvSND6oErxIgvdL jhz2kt8lVZzCROarrYyV4zUdrdcAXdf1RnmJPudeQYQkjTnDqsRfNmFy0SfEZwe8o1A== 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 A5374606A31B for ; Tue, 27 Oct 2026 02:28:54 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.2 smtp.subspace.kernel.org A5374606A31B 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-8a01ea9e318so5171578b3a.2 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=0tE/IcyY+VCUS8mfKouHQMZzsTI75HiWNJOl/Xp/c1IquLVDHBd7Jf/CoMwYzLZhoo kThaOErDAAwldMbPnes6zan3tB4sXH2q3ngpd4v8UjEDiYu2oRyPWzFfjmQgTyZHfaSJ R7i8SFtPqR9QNP/HNsvuoPGwqN+Me1N9wuYuT381b8DRWZtFH1byvbOvkFNFC0ZqhjC6 WLtWKaSkHGy4TVvHYrDikFrudQY5rrurvnHNkbrZKznjRLN7dxJDi95R1O6GiFA8y3rJ DF0Jo5BniKr5lK8yuUpQYiCNQ7di2d85g+8IKOvpE7e3u4Kkbimf25ZmqwvawWl4V3NC Cyyw== X-Forwarded-Encrypted: i=1; AKwUvBxpVLUq1jsx3PZpymzOsxmLm5sQwv+zvL1W/wQNlmwqMqcne3Bn4WB39LXgATG7oGmPhQhOiHtJvgZkboQ=@vger.kernel.org X-Gm-Message-State: AFq9FYIhDxmSul7obnywKiALvmBg+WGRl4XG4vXNdjeB4NGjtflTo7N9 gUifFcMne38ZVikgaiR1rQ3tfbzJ2zgJSIMOfwLUBoJRl4cOBPyO5Q5+G5nLP29tZfU9NsgGUpZ tqQgKIA== 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: linux-kernel@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);