From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mta1.migadu.com (out-12.mta1.migadu.com [95.215.58.12]) (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 E10E51A0BF1 for ; Wed, 30 Sep 2026 05:50:03 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=95.215.58.12 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1790747405; cv=none; b=SpOEWaxA/TILkzkb25wfMtn3bT/L0EmSXQsmR8vmfQNQR5Ng5fE7/yrWSbLjXwDBcUKuZWaFaQ1AqoLvpu+tlOIXyA4/WuQ88e0WLpbrHegeERyGMHlKbISLl9roL6zI028fl8oExEYTF48N6WIWDVb/HVUCdZ0QgqtXiK/kb8I= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1790747405; c=relaxed/simple; bh=VoUWKhSsc5jAqRZ0m1ClkrcHD3Ijqo+qGS3UdFNAQNM=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=b+J8MPxVrCq5kT0duee02+K5LCUx/pFlZNT8AOMNmDpJvItPvklzN2zaGDh25FtwHIXwuuNH3WuknCizbOtZcEnp0rEEO/N43MeWVcv84mQ8NuHBf71FtOc2jLAC3ZNSy8AlU+5glY8VtYsvflae+KtfKadJBdL+HPNN1LuVRLc= 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=qRhL5b/b; arc=none smtp.client-ip=95.215.58.12 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="qRhL5b/b" X-Envelope-To: linux-kernel@vger.kernel.org DKIM-Signature: a=rsa-sha256; bh=VoUWKhSsc5jAqRZ0m1ClkrcHD3Ijqo+qGS3UdFNAQNM=; c=simple/simple; d=linux.dev; h=from:to:subject:date:message-id:mime-version:content-type; s=key1; t=1790747401; v=1; x=1791352201; b=qRhL5b/bGptX1wYy+tYW2MR+NTrvxxBREK6ZFx7FcXG67//mGjifld9aPjWIt9W50ng2h2n/ siN2rGdpz1ClmOfXaVAwAMk/SYy8l4hO+/1NlVmtRTAKB4LzB7RcF1ONE63kRhyRQSVxdl/c/hj Mji0UTe8OV9bGqXyLOuqHv9M= X-Envelope-To: linux-kernel@vger.kernel.org Received: by smtp.migadu.com with ESMTPS id f663c2b6a0792e28; Wed, 30 Sep 2026 05:50:01 +0000 X-Mizu-Trace-ID: f663c2b6a0792e28 X-Migadu-Flow: FLOW_OUT Message-ID: Date: Wed, 30 Sep 2026 13:49:54 +0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH net] tls: skip empty data records in tls_sw_splice_read() To: netdev-bot+sinfo@kernel.org Cc: John Fastabend , Jakub Kicinski , Sabrina Dubroca , "David S. Miller" , Eric Dumazet , Paolo Abeni , Simon Horman , Dave Watson , netdev@vger.kernel.org, linux-kernel@vger.kernel.org, Chuck Lever References: <20260930052636.166007-1-qingfang.deng@linux.dev> <179074618718.31693.10040628020266132112@kernel.org> From: Qingfang Deng In-Reply-To: <179074618718.31693.10040628020266132112@kernel.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 2026/9/30 13:29, netdev-bot+sinfo@kernel.org wrote: > Hi! > > This is an automated message. This series looks like a fix, but its > commit messages seem to be missing some information: > > - Whether the issue was actually triggered, or is only theoretical > (e.g. found by code inspection). If it was triggered please include > the symptoms, like the stack trace or error messages. > > Please do not repost the series just to address the above. Instead, > reply to this email with the missing information, so that reviewers > can take it into account. If the series needs another revision for > other reasons, please include the information in the commit messages > then. > > The evaluation is done by an LLM so it may be wrong, if you think > that is the case please reply and explain. Quoting Sashiko's reply: > When an application invokes splice() on a TLS 1.3 socket and a > 0-length record arrives, rxm->full_len is 0, making chunk 0. > net/tls/tls_sw.c:tls_sw_splice_read() { ... chunk = min_t(unsigned > int, rxm->full_len, len); copied = skb_splice_bits(skb, sk, > rxm->offset, pipe, chunk, flags); if (copied < 0) goto splice_requeue; > if (copied < rxm->full_len) { rxm->offset += copied; rxm->full_len -= > copied; goto splice_requeue; } consume_skb(skb); splice_read_end: > tls_rx_reader_unlock(sk, ctx); return copied ? : err; } Because copied > is 0, the copied < rxm->full_len check fails, the SKB is consumed, and > the function returns 0. Returning 0 from a splice operation signals > End-of-File to userspace, which would erroneously drop the live > connection. Best regards,