* [stable regression] tcp: make connect() mem charging friendly
@ 2015-04-14 7:32 Ben Hutchings
2015-04-14 12:19 ` Eric Dumazet
0 siblings, 1 reply; 3+ messages in thread
From: Ben Hutchings @ 2015-04-14 7:32 UTC (permalink / raw)
To: netdev, stable; +Cc: Eric Dumazet, 782515
[-- Attachment #1: Type: text/plain, Size: 1318 bytes --]
Commit 355a901e6cf1b2b763ec85caa2a9f04fbcc4ab4a ("tcp: make connect()
mem charging friendly") was backported to various stable branches:
v3.10.73: e64a85197b3f tcp: make connect() mem charging friendly
v3.12.40: d06381e8aac5 tcp: make connect() mem charging friendly
v3.14.37: 5a8e8f482b4a tcp: make connect() mem charging friendly
v3.18.11: e8f117f002ca tcp: make connect() mem charging friendly
v3.13.11-ckt19: de023863df9d tcp: make connect() mem charging friendly
v3.16.7-ckt9: bea5f6ef9fcb tcp: make connect() mem charging friendly
On the 3.16 branch, this has resulted in a regression for TCP Fast Open:
<https://bugs.debian.org/782515>. The BUG() at the top of
tcp_transmit_skb() fires as tcp_skb_pcount(skb) == 0.
tcp_send_syn_data() does:
memcpy(syn_data->cb, syn->cb, sizeof(syn->cb));
Since commit cd7d8498c9a5 ("tcp: change tcp_skb_pcount() location") this
is sufficient to set the GSO segment count correctly. But in older
branches (< 3.18) the GSO segment count in skb_shared_info is used and
is no longer copied by tcp_send_syn_data().
All the versions listed above, except v3.18.11, appear to have suffered
this regression.
Ben.
--
Ben Hutchings
Editing code like this is akin to sticking plasters on the bleeding stump
of a severed limb. - me, 29 June 1999
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 811 bytes --]
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [stable regression] tcp: make connect() mem charging friendly
2015-04-14 7:32 [stable regression] tcp: make connect() mem charging friendly Ben Hutchings
@ 2015-04-14 12:19 ` Eric Dumazet
2015-04-14 19:12 ` Ben Hutchings
0 siblings, 1 reply; 3+ messages in thread
From: Eric Dumazet @ 2015-04-14 12:19 UTC (permalink / raw)
To: Ben Hutchings; +Cc: netdev, stable, Eric Dumazet, 782515
On Tue, 2015-04-14 at 08:32 +0100, Ben Hutchings wrote:
> Commit 355a901e6cf1b2b763ec85caa2a9f04fbcc4ab4a ("tcp: make connect()
> mem charging friendly") was backported to various stable branches:
>
> v3.10.73: e64a85197b3f tcp: make connect() mem charging friendly
> v3.12.40: d06381e8aac5 tcp: make connect() mem charging friendly
> v3.14.37: 5a8e8f482b4a tcp: make connect() mem charging friendly
> v3.18.11: e8f117f002ca tcp: make connect() mem charging friendly
> v3.13.11-ckt19: de023863df9d tcp: make connect() mem charging friendly
> v3.16.7-ckt9: bea5f6ef9fcb tcp: make connect() mem charging friendly
>
> On the 3.16 branch, this has resulted in a regression for TCP Fast Open:
> <https://bugs.debian.org/782515>. The BUG() at the top of
> tcp_transmit_skb() fires as tcp_skb_pcount(skb) == 0.
>
> tcp_send_syn_data() does:
>
> memcpy(syn_data->cb, syn->cb, sizeof(syn->cb));
>
> Since commit cd7d8498c9a5 ("tcp: change tcp_skb_pcount() location") this
> is sufficient to set the GSO segment count correctly. But in older
> branches (< 3.18) the GSO segment count in skb_shared_info is used and
> is no longer copied by tcp_send_syn_data().
>
> All the versions listed above, except v3.18.11, appear to have suffered
> this regression.
>
> Ben.
>
Hi Ben
Sorry to ear that. Have you already fixed this, or are you asking for
help ?
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [stable regression] tcp: make connect() mem charging friendly
2015-04-14 12:19 ` Eric Dumazet
@ 2015-04-14 19:12 ` Ben Hutchings
0 siblings, 0 replies; 3+ messages in thread
From: Ben Hutchings @ 2015-04-14 19:12 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev, stable, Eric Dumazet, 782515
[-- Attachment #1: Type: text/plain, Size: 1761 bytes --]
On Tue, 2015-04-14 at 05:19 -0700, Eric Dumazet wrote:
> On Tue, 2015-04-14 at 08:32 +0100, Ben Hutchings wrote:
> > Commit 355a901e6cf1b2b763ec85caa2a9f04fbcc4ab4a ("tcp: make connect()
> > mem charging friendly") was backported to various stable branches:
> >
> > v3.10.73: e64a85197b3f tcp: make connect() mem charging friendly
> > v3.12.40: d06381e8aac5 tcp: make connect() mem charging friendly
> > v3.14.37: 5a8e8f482b4a tcp: make connect() mem charging friendly
> > v3.18.11: e8f117f002ca tcp: make connect() mem charging friendly
> > v3.13.11-ckt19: de023863df9d tcp: make connect() mem charging friendly
> > v3.16.7-ckt9: bea5f6ef9fcb tcp: make connect() mem charging friendly
> >
> > On the 3.16 branch, this has resulted in a regression for TCP Fast Open:
> > <https://bugs.debian.org/782515>. The BUG() at the top of
> > tcp_transmit_skb() fires as tcp_skb_pcount(skb) == 0.
> >
> > tcp_send_syn_data() does:
> >
> > memcpy(syn_data->cb, syn->cb, sizeof(syn->cb));
> >
> > Since commit cd7d8498c9a5 ("tcp: change tcp_skb_pcount() location") this
> > is sufficient to set the GSO segment count correctly. But in older
> > branches (< 3.18) the GSO segment count in skb_shared_info is used and
> > is no longer copied by tcp_send_syn_data().
> >
> > All the versions listed above, except v3.18.11, appear to have suffered
> > this regression.
> >
> > Ben.
> >
>
> Hi Ben
>
> Sorry to ear that. Have you already fixed this, or are you asking for
> help ?
That was as far as I got this morning. I can probably come up with a
fix later if you don't sooner.
Ben.
--
Ben Hutchings
Editing code like this is akin to sticking plasters on the bleeding stump
of a severed limb. - me, 29 June 1999
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 811 bytes --]
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2015-04-14 19:12 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-04-14 7:32 [stable regression] tcp: make connect() mem charging friendly Ben Hutchings
2015-04-14 12:19 ` Eric Dumazet
2015-04-14 19:12 ` Ben Hutchings
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.