Eric Dumazet <eric.duma...@gmail.com> writes: > On Fri, 2018-01-26 at 00:44 +1100, Daniel Axtens wrote: >> Hi Eric, >> >> > May I ask which tree are you targeting ? >> > >> > ( Documentation/networking/netdev-FAQ.txt ) >> >> I have been targeting net-next, but I haven't pulled for about two >> weeks. I will rebase and if there are conflicts I will resend early next >> week. >> >> > Anything touching GSO is very risky and should target net-next, >> > especially considering 4.15 is released this week end. >> > >> > Are we really willing to backport this intrusive series in stable >> > trees, or do we have a smaller fix for bnx2x ? >> >> I do actually have a smaller fix for bnx2x, although it would need more work: >> https://patchwork.ozlabs.org/patch/859410/ >> >> It leaves open the possibility of too-large packets causing issues on >> other drivers. DaveM wasn't a fan: >> https://patchwork.ozlabs.org/patch/859410/#1839429 > > Yes, I know he prefers a generic solution, but I am pragmatic here. > Old kernels are very far from current GSO stack in net-next. > > Backporting all the dependencies is going to be very boring/risky.
OK, so how about: - first, a series that introduces skb_gso_validate_mac_len and uses it in bnx2x. This should be backportable without difficulty. - then, a series that wires skb_gso_validate_mac_len into the core - validate_xmit_skb for instance, and reverts the bnx2x fix. This would not need to be backported. If that's an approach we can agree on, I am ready to send it when net-next opens again. Regards, Daniel _______________________________________________ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
