On Fri, 1 Jun 2018, Matthew Wilcox wrote: > > >> My take on the root cause: > > >> When adding data to an skb, new data is appended to the current > > >> fragment if the new chunk immediately follows the last one: by simply > > >> increasing the frag->size, skb_frag_size_add(). > > >> See include/linux/skbuff.h:skb_can_coalesce() callers. > > > > Oooh, sneaky: > > return page == skb_frag_page(frag) && > > off == frag->page_offset + skb_frag_size(frag); > > > > Originally I was thinking that slab red-zoning would get triggered > > too, but I see the above is checking to see if these are precisely > > neighboring allocations, I think. > > > > But then ... how does freeing actually work? I'm really not sure how > > this seeming layering violation could be safe in other areas? So if there are two neighboring slab objects that the page struct addresses will match and the network code will coalesce the objects even if they are in two different slab objects? The check in skb_can_coalesce() must verify that these are distinct slab object. Simple thing would be to return false if one object is a slab object but then the coalescing would not work in a single slab object either. So what needs to happen is that we need to check if this is 1) A Page. Then the proper length of the segment within we can coalesce is the page size. 2) A slab page. Then we can use ksize() to establish the end of the slab object and we should only coalesce within that boundary.
