On Wed, Mar 1, 2017 at 3:15 PM, Eric Dumazet <eduma...@google.com> wrote: > On Wed, Mar 1, 2017 at 3:09 PM, Cong Wang <xiyou.wangc...@gmail.com> wrote: > >> >> But I doubt skb_orphan() is the solution here, shouldn't we just >> update sk->sk_wmem_alloc with skb->truesize changes? > > Is it worth it ? Apart from syszkaller I mean... > > We started with something that had a real impact on real workloads. > > 158f323b9868b59967ad96957c4ca388161be321 net: adjust skb->truesize in > pskb_expand_head() > > Note that auditing the stack took me a while.
I don't know how sk refcnt could work correctly without making sk_wmem_alloc correctly. We certainly could just call skb_orphan() is we don't need skb->sk any more, probably like the frag case, but for this case, the neigh one, the skb's sitting in neigh->arp_queue are not going to be freed unless in failed case, therefore skb->sk should not be orphaned so early.