On Thu, 22 Oct 2026, [email protected] wrote: > [Severity: Medium] > Can this break return 0 while the next record is still being parsed, with > nothing left to wake nvme-tcp? > > data_ready_work is only queued if msg_ready is already set. For the 16th > empty record, tls_rx_rec_done() calls tls_strp_check_rcv(&ctx->strp, false). > If tls_strp_read_sock() returns -ENOMEM, the parse is handed off to > strp->work and msg_ready stays 0:
Agreed... but the gap it leads to is not one this patch opens. When the strparser defers a parse to strp->work, tls_strp_work() announces the record through saved_data_ready alone, and a read_sock consumer that installed its own callback after the handshake never hears about it. That is reachable today after any record, data or empty. What the cap changes is the number of allocation failures that reach that state at one point in the loop, from two to one. Both need GFP_ATOMIC to fail during a run of sixteen consecutive empty records, and both end in the same place. The fix is in the deferred announce, so that a parse completed by strp->work reaches the callback the consumer installed. My preference would be to fix that as a separate patch so it can get backported. If netdev maintainers would rather have the work item queued whenever the receive queue is non-empty at the break, that is a one-line change and I can send a v7 with it. Otherwise I plan to leave this patch as is. Let me know. -- Chuck Lever (Come to NFS bake-a-thon! https://nfsv4bat.org)
