Re: [PATCH net-next v2 5/8] tls: consume empty data records in tls_sw_recvmsg()

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

On Mon, Oct 05, 2026, netdev-bot+sashiko@kernel.org wrote:
> > +		if (!chunk && control == TLS_RECORD_TYPE_DATA) {
> > +			if (!darg.zc)
> > +				consume_skb(darg.skb);
> > +
> > +			/* An empty record still marks a boundary. */
> > +			msg->msg_flags |= MSG_EOR;
> > +			continue;
> > +		}
>
> [Severity: High]
> This keeps empty records off rx_list. Does the receive loop still fail to
> make progress on them, though?

It does, and this patch does not change that. Before it, every arm
of the loop reached "decrypted += chunk" and "len -= chunk" with
chunk == 0 and went around again. The patch stops the peek and
async arms from queueing those records on rx_list and leaves the
loop's bounds alone.

The patch description cites the loop to explain why rx_list grows,
and I can see it reads as a claim that the patch bounds the loop.
I'll reword it in v3.


> In-kernel MSG_DONTWAIT callers never receive a signal, so they cannot use
> this exit. One example is svc_tcp_sock_recvmsg() in net/sunrpc/svcsock.c:

True, and also true before this series.


> should the empty-record branch break out once decrypted + copied >= target?

Returning bytes already copied instead of waiting out a run of
empty records is reasonable, and I'll look at it for v3. With
nothing copied, a blocking reader has no return value that is not
EOF or an error, so that case keeps looping until a record with
data, a signal, or the end of the run.


-- 
Chuck Lever (Come to NFS bake-a-thon! https://nfsv4bat.org)