On Mon, Oct 05, 2026, [email protected] 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)
