From nobody Sun Feb 8 12:37:03 2026 Received: from out-185.mta0.migadu.com (out-185.mta0.migadu.com [91.218.175.185]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 04DF722B581; Fri, 25 Apr 2025 06:01:11 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=91.218.175.185 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1745560874; cv=none; b=MxoDYE69m1L3vq35Tf8Qa73PDuaTUrgef08OdL9zn/zG0yKk1OwI3unAFFf+WoXY8/yOdyfNyqGBewUsn1XPMiP6ob2lysFzxj1zgtETcN3EQaPISdXrd7bhtYequX3aPfGJHPJc1HQZTjduKE6XcoMMQnuQy8TLKTSRBY3jCK8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1745560874; c=relaxed/simple; bh=og8M9B4FHvzUgLuT1E7FT8iMPtVnMg+YA9UWQPvH2NE=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=TxXmJiPjCOYDGQEVhUoUSu0lA4tUhZcW9SfLLsHnPV6gvYvbWwQ0rvMhgSmFgH3szUp8EwY2APV2N6bFnBrP/v1HgfFBuf7QA1RGcaoKgD02VTXCatNalEKYoZEj5glFVFsmrvFzZjW7CGmVAEwWiWb4Gv+l0COmU2eNj7kethg= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b=RchA3BKr; arc=none smtp.client-ip=91.218.175.185 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b="RchA3BKr" X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1745560869; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=TdVpzvtZn2JQNi80SAYrqqWduzBTLxagERvM+Rtaows=; b=RchA3BKrE9IucRTtRair04PwzAS8I77OfG5Nmv4aQUBFgORhj6lpMvs8ZtSe1npK9qNXOn iTTHbZzZkmv1Qy3zd9mhC3k4vLKHOJ1k4bEq2EFhOtIaqSajOprVYotoRvAd+mAt1IMQbx zxpidx9FFroaXe0qg+3Tjv3vx55NiyQ= From: Jiayuan Chen To: bpf@vger.kernel.org Cc: mrpre@163.com, Jiayuan Chen , Cong Wang , Boris Pismenny , John Fastabend , Jakub Kicinski , "David S. Miller" , Eric Dumazet , Paolo Abeni , Simon Horman , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , Martin KaFai Lau , Eduard Zingerman , Song Liu , Yonghong Song , KP Singh , Stanislav Fomichev , Hao Luo , Jiri Olsa , Mykola Lysenko , Shuah Khan , netdev@vger.kernel.org, linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org Subject: [PATCH bpf-next v1 1/2] ktls, sockmap: Fix missing uncharge operation Date: Fri, 25 Apr 2025 13:59:57 +0800 Message-ID: <20250425060015.6968-2-jiayuan.chen@linux.dev> In-Reply-To: <20250425060015.6968-1-jiayuan.chen@linux.dev> References: <20250425060015.6968-1-jiayuan.chen@linux.dev> 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 X-Migadu-Flow: FLOW_OUT Content-Type: text/plain; charset="utf-8" When we specify apply_bytes, we divide the msg into multiple segments, each with a length of 'send', and every time we send this part of the data using tcp_bpf_sendmsg_redir(), we use sk_msg_return_zero() to uncharge the memory of the specified 'send' size. However, if the first segment of data fails to send, for example, the peer's buffer is full, we need to release all of the msg. When releasing the msg, we haven't uncharged the memory of the subsequent segments. This modification does not make significant logical changes, but only fills in the missing uncharge places. This issue has existed all along, until it was exposed after we added the apply test in test_sockmap: commit 3448ad23b34e ("selftests/bpf: Add apply_bytes test to test_txmsg_red= ir_wait_sndmem in test_sockmap") Reported-by: Cong Wang Closes: https://lore.kernel.org/bpf/aAmIi0vlycHtbXeb@pop-os.localdomain/T/#t Fixes: d3b18ad31f93 ("tls: add bpf support to sk_msg handling") Signed-off-by: Jiayuan Chen Reviewed-by: Cong Wang --- net/tls/tls_sw.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/net/tls/tls_sw.c b/net/tls/tls_sw.c index f3d7d19482da..fc88e34b7f33 100644 --- a/net/tls/tls_sw.c +++ b/net/tls/tls_sw.c @@ -908,6 +908,13 @@ static int bpf_exec_tx_verdict(struct sk_msg *msg, str= uct sock *sk, &msg_redir, send, flags); lock_sock(sk); if (err < 0) { + /* Regardless of whether the data represented by + * msg_redir is sent successfully, we have already + * uncharged it via sk_msg_return_zero(). The + * msg->sg.size represents the remaining unprocessed + * data, which needs to be uncharged here. + */ + sk_mem_uncharge(sk, msg->sg.size); *copied -=3D sk_msg_free_nocharge(sk, &msg_redir); msg->sg.size =3D 0; } --=20 2.47.1