Re: [PATCH net-next v10 3/7] tls: Re-present partially-consumed records in tls_sw_read_sock()

["Chuck Lever" <cel@kernel.org>]

On Tue, May 12, 2026, at 8:17 PM, Jakub Kicinski wrote:
> On Tue, 12 May 2026 14:52:59 +0200 Sabrina Dubroca wrote:
>> > __tcp_read_sock() handles the same case by leaving the unread
>> > bytes available for the next iteration to re-present, though
>> > its mechanism (sequence-number re-lookup) differs from the TLS
>> > path's explicit queue management. Adopt the same loop-level
>> > behavior here: update rxm->offset and rxm->full_len, requeue
>> > the skb to the head of rx_list, and continue. The next
>> > iteration pops the same skb and re-presents the unread bytes
>> > to read_actor().
>> > 
>> > Fixes: 662fbcec32f4 ("net/tls: implement ->read_sock()")  
>> 
>> Fixes typically go through "net", not "net-next".
>
> Just to be sure - no in-kernel reader partially consumes today
> without setting desc to 0, right?

Correct, today's only read_sock TLS consumer (nvme/tcp) does not
exercise the partial-consume path. But, this fix is a prerequisite
for upcoming consumers; specifically NFSD is about to be converted
from sock_recvmsg to read_sock. NFSD’s multi-fragment RPC parser
legitimately returns used < len with desc->count still non-zero
when a TLS record straddles an RPC fragment boundary.


> If so a more appropriate direction would be to say that in
> the commit message and drop the Fixes tag.

I’ll drop the Fixes: tag and route 2/7 and 3/7 through net-next.

Note that 7/7 in this series also bears a Fixes: tag. Should
that one go through net instead?


-- 
Chuck Lever