On Mon, May 21, 2018, Johannes Erdfelt <[email protected]> wrote: > There are two nested frag_list uses, with the newly introduced skb > ffff92544a0bfe00 having nr_frags == 0. > > Eventually openvswitch will want to fragment the skb for the upcall, > which ends up in skb_segment and finally crashes on the BUG_ON(!nfrags) > (for skb ffff92544a0bfe00 in the examples above) > > It's not clear to me if the problem is in openvswitch or in the > networking core. > > Why does openvswitch set OVS_FRAG_TYPE_FIRST for any skb with > SKB_GSO_UDP set even if it's not a fragmented packet? > > Would it ever make sense for ip_frag_reasm to see an skb large enough to > require the use of frag_list?
I've spent a lot of time doing research and further debugging on this. It's theoretically possible to send a large 60k GSO skb that has the MF bit set and then a small second IP fragment. This kind of IP fragmentation would not normally be seen because GSO skbs can generally hold packets large enough to not need fragmentation. However, they could certainly be created by hand. It also turns out that what ip_frag_reasm is doing is expected. There was a discussion last year about this and it was determined that nested frag_list entries can happen and should be expected. The discussion even used ip_frag_reasm as an example. http://www.openwall.com/lists/kernel-hardening/2017/04/27/7 http://www.openwall.com/lists/kernel-hardening/2017/04/27/12 As a result, it appears that skb_segment needs to be fixed to handle the skb geometry being seen and it's not openvswitch doing anything incorrect. There is likely some optimization that can happen in openvswitch to avoid handing off unfragmented packets to the networking core to be reassembled (especially in the GSO case), but it should just be a performance optimization. JE _______________________________________________ discuss mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
