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]
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ