On Wed, 2015-09-16 at 01:48 +0200, Florian Westphal wrote: > > What I don't understand is why you see this with fragmented ipv6 > packets only (and not with all ipv6 forwarded skbs). > > Something like this copy-pastry from ip_finish_output2 should fix it:
That works; thanks. Tested-by: David Woodhouse <david.woodho...@intel.com> A little extra debugging output shows that the offending fragments were arriving here with skb_headroom(skb)==10. Which is reasonable, being the Solos ADSL card's header of 8 bytes followed by 2 bytes of PPP frame type. The non-fragmented packets, on the other hand, are arriving with a headroom of 42 bytes. Could something else already have reallocated them before they get that far? (Do we have any way to gather statistics on such reallocations? It seems that might be useful for performance investigation.) Johannes and I were talking on IRC yesterday about trying to make this kind of thing easier to reproduce without odd hardware. We postulated a skb_torture() function which, when an appropriate debugging option was enabled, would randomly screw around with the skb in various interesting ways — shifting the data down so that there's no headroom, deliberately making it *non-linear*, temporarily cloning it and freeing the clone a couple of seconds later, etc. Then we could insert calls to skb_torture() in interesting places like netif_rx(), ip6_finish_output2() and anywhere else that seems appropriate (perhaps with flags to indicate *what* kind of torture is permissible in certain locations). And see what breaks... -- David Woodhouse Open Source Technology Centre david.woodho...@intel.com Intel Corporation
smime.p7s
Description: S/MIME cryptographic signature
