Ah well... No, its not appropriate to grow sk_buff by 16 bytes, sorry. You could not change struct inet6_skb_parm, but define IP6CB as a compound struct ip6cb { struct inet6_skb_parm foo; struct in6_
I think it should be possible to solve that using the IP6CB() approach that Eric suggested. Hopefully we can make that approach fly. -- To unsubscribe from this list: send the line "unsubscribe lvs-d
That does seem very promising but while implementing it I hit a problem. struct tcp_skb_cb includes a field of type struct inet6_skb_parm. And expanding struct inet6_skb_parm by 16 bytes means that s
Author: Hannes Frederic Sowa <hannes@xxxxxxxxxxxxxxxxxxx>
Date: Wed, 16 Oct 2013 02:53:22 +0200
Hmm, that reminds me on the following bug report which would be nice we could solve in one go, too: http://www.spinics.net/lists/netdev/msg250785.html Greetings, Hannes -- To unsubscribe from this li
This was to point that between IPVS and ipv6 stack we might have a delay, and daddr was maybe pointed to a freed memory. IP6CB only uses 24 bytes, so I think you would be safe adding 16 bytes. -- To
I thought of you when I wrote that comment :) I can change that to passing a value if there is a risk the reference could become invalid. To be honest I am more worried that skb->cb might be clobbere
Please no ;) So we pass a reference. What guarantee do we have daddr points to valid memory (not already freed/reused) ? I guess things like NFQUEUE could happen ? -- To unsubscribe from this list: s
In v3.9 6fd6ce2056de2709 ("ipv6: Do not depend on rt->n in ip6_finish_output2()") changed the behaviour of ip6_finish_output2() such that it creates and uses a neigh entry if none is found. Subsequen