On Fri, May 8, 2026 at 2:55 PM Jacob Keller <[email protected]> wrote: > > 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.
It looks like messages on this chain have been cc-ed to stable since your first message. Is that sufficient, or do I need to resubmit (e.g. v3) with stable in the cc list? -John-
