On 01/27/2016 10:07 PM, Alexei Starovoitov wrote:
On Wed, Jan 27, 2016 at 12:17 PM, Daniel Borkmann <daniel@...> wrote:
On 01/27/2016 08:42 PM, Alexei Starovoitov wrote:
yep. it's an ovs gimmick. pskb_may_pull() is useless for us.
I believe from the old nft ingress discussion. ;) But maybe it was just
Was still thinking if we better should extend this (rather slow-path)I don't think so. only pktgen does ugly things.
test into handling it more gracefully:
!skb_shared(skb) && pskb_expand_head(skb, 0, 0, GFP_ATOMIC);
Shared skbs should be rather rare. But, there seem to be tricky things
with skb_get() or raw atomic_inc(&skb->users) that /could/ cause a BUG
when calling into pskb_expand_head() in our path. Taking pktgen aside,
I remember from an old netdev discussion, that with taps shared skbs
and pskb_expand_head() should cause issues. Going through the pf_packet
it's a requirement of the IP stack to have users == 1.
we had this discussion before. I will try to dig out my old email.
a different issue w/ other actions (or not up to date fact anymore).
btw, there is skb_make_writable() that used by netfilter,There's also skb_ensure_writable(), but seems to be doing more than we
but doing skb_cloned(skb) && !skb_clone_writable() && pskb_expand
is faster and probably cleaner.
Yeah, so I'll do some more testing and get it out for -net-next when it
opens up next few days hopefully, keeping also Ashhad in the loop (meanwhile
you can use the patch).