On 5/7/2026 7:37 PM, John Ousterhout wrote: > Correct: this patch only applies to the ice driver before its conversion. > > The patch applies to versions 6.18.27 and 6.12.86. I believe the bug > may also be present in 6.6.137, but the code has a slightly different > structure there (the function ice_put_rx_mbuf doesn't yet exist in > that version) so the patch would need to be reworked a bit. > > This situation isn't all that rare. It isn't a zero-length packet that > triggers it; it seems to happen if a packet uses every available byte > in a buffer, ending precisely at the end of the buffer. When this > happens, the NIC seems to generate an extra zero-length "buffer". This > happens quite frequently (thousands of times per second in some of my > workloads). > > What keeps corruption from happening constantly is that there is only > a problem if the "other half" of the buffer page is still active when > the 0-length buffer is received from the NIC. I suspect that with TCP > this is pretty unlikely: packet buffers get recycled quickly. If the > other half is not in use, then it doesn't matter whether the page gets > "flipped" while processing the 0-length buffer. I ran into this > problem because I was testing Homa under conditions that caused some > packet buffers to stay alive for longer periods of time. > > -John- Right. So I think we need to make sure the patch is cc'd to stable. Technically it doesn't strictly follow any of the 3 rules, but its closest to 3 with a clarification that there is no upstream equivalent due to the libeth Rx refactor.
Thanks, Jake
