From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mta0.migadu.com (out-54.mta0.migadu.com [91.218.175.54]) (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 576D8477E40 for ; Wed, 30 Sep 2026 09:24:26 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=91.218.175.54 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1790760269; cv=none; b=pPJM6fQfUg7+mNMmQBVll6Yiq7p9OH3Bc+Dcq1ZoX6UByQULwumJv9uM9+Znup2808ZH4FUHTd2VtAthuGCxAgQ30Vv0BZo9wQ/2Wmd8JpYi/tZO+DP5AyspCDd7TViR7yxrdKvjgq3sBYx92L+bQ4FNO/IlhONbr6NV0K2fYXU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1790760269; c=relaxed/simple; bh=CgKPdajqhtSYylupqHJTybBjAIiLXNiqOqyoKGQx6Ps=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=b4mOb9ZfmhB8F3lfUJnszCDu4vcL6i3oHA4Nh6AAYPo2goTxlzxJTpx8IYNOrz/u78jaMeTGHioNpHc0dJh7QHI2fCYakpe/gZZy9lKpdSHZUxNuG/Av9SVA2rGkRkS7LPzQV/kFGwwNvTFTKh8XtbwPiPtO1oJku/MoQ3dUif0= 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=dwcBtf36; arc=none smtp.client-ip=91.218.175.54 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="dwcBtf36" X-Envelope-To: linux-kernel@vger.kernel.org DKIM-Signature: a=rsa-sha256; bh=CgKPdajqhtSYylupqHJTybBjAIiLXNiqOqyoKGQx6Ps=; c=simple/simple; d=linux.dev; h=from:to:subject:date:message-id:mime-version:content-type; s=key1; t=1790760265; v=1; x=1791365065; b=dwcBtf36QDTxjwd9eZf9wfFmLky24hLdcjpM9oJZC6F0MUDzEWm5/LxfzmV/zD3QJvanchpB DVnKsZNbI8yAl9juMRK7J959LUrbVukZ57sQM1w/ubSRhxLyTMrvWTPz8l4r52d2OycBMzgMHPw gTbaZZCAiE8gkqepz7ZHIlKA= X-Envelope-To: linux-kernel@vger.kernel.org Received: by smtp.migadu.com with ESMTPS id 4ba59fb9213cd29c; Wed, 30 Sep 2026 09:24:25 +0000 X-Mizu-Trace-ID: 4ba59fb9213cd29c X-Migadu-Flow: FLOW_OUT Message-ID: <465aa0d9-b1b2-4c85-9cbf-e6ed296b7b12@linux.dev> Date: Wed, 30 Sep 2026 17:24:18 +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: Sabrina Dubroca , Chuck Lever Cc: John Fastabend , Jakub Kicinski , "David S. Miller" , Eric Dumazet , Paolo Abeni , Simon Horman , Dave Watson , netdev@vger.kernel.org, linux-kernel@vger.kernel.org References: <20260930052636.166007-1-qingfang.deng@linux.dev> From: Qingfang Deng In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 2026/9/30 17:13, Sabrina Dubroca wrote: > 2026-09-30, 13:26:36 +0800, Qingfang Deng wrote: >> tls_sw_splice_read() returns 0 after receiving an empty application >> record. This looks like EOF for splice(), even though the connection >> remains open and more data may be available. >> >> Consume empty application records and retry the receive path instead, >> following the approach used in tls_sw_read_sock() since commit >> 3be28e2c9cd0 ("net/tls: Consume empty data records in tls_sw_read_sock()"). > This is similar to what Chuck proposed in July: > https://lore.kernel.org/all/20260726-tls-follow-on-v1-2-99bf4cc1c729@kernel.org > > but Chuck's patch had some extra bits (handling of the "released" flag > and of signal_pending). > > His series also had a selftest which should be included too > https://lore.kernel.org/all/20260726-tls-follow-on-v1-6-99bf4cc1c729@kernel.org/ Thanks for the information. I prefer his series. -- pw-bot: cr