netdev - Re: [PATCH net-next] tcp: avoid expensive pskb_expand

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1334778567.2472.330.camel@edumazet-glaptop>
Date:	Wed, 18 Apr 2012 21:49:27 +0200
From:	Eric Dumazet <eric.dumazet@...il.com>
To:	Vijay Subramanian <subramanian.vijay@...il.com>
Cc:	David Miller <davem@...emloft.net>,
	netdev <netdev@...r.kernel.org>,
	Tom Herbert <therbert@...gle.com>,
	Neal Cardwell <ncardwell@...gle.com>,
	Maciej Żenczykowski <maze@...gle.com>,
	Yuchung Cheng <ycheng@...gle.com>
Subject: Re: [PATCH net-next] tcp: avoid expensive pskb_expand_head() calls

On Wed, 2012-04-18 at 12:41 -0700, Vijay Subramanian wrote:
> >  {
> >        if (skb_cloned(skb) && pskb_expand_head(skb, 0, 0, GFP_ATOMIC))
> >                return -ENOMEM;
> > @@ -1134,6 +1138,7 @@ int tcp_trim_head(struct sock *sk, struct sk_buff *skb, u32 len)
> >        __pskb_trim_head(skb, len);
> >
> >        TCP_SKB_CB(skb)->seq += len;
> > +       TCP_SKB_CB(skb)->header.offset_ack = 0;
> >        skb->ip_summed = CHECKSUM_PARTIAL;
> >
> >        skb->truesize        -= len;
> >
> 
> Eric,
> tcp_trim_head() also updates skb->truesize as above. But is this the
> right thing to do when only offsets/pointers are updated. If
> __pskb_trim_head() removes len bytes but does not actually free
> memory,
> should truesize be updated?  This could happen if data in the linear
> part is acked.  This behavior takes place currently even without your
> patch, by the way.
> 

Thats ok.

__pskb_trim_head() callers are responsible for taking care of truesize
changes.

By the way, its always complex to guess truesize changes. removing some
bytes in skb head doesnt free memory, so in fact we should not change
truesize in this case.

But only one skb in tcp write queue might have a slightly wrong
truesize, its not a big deal.

Problem with skb->truesize is mostly in input path, when first
skb->truesize is not correctly set by drivers, upper stack can
accumulate errors in socket receive queue.





--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html