This commit ensures that lost_cnt_hint is correctly updated in
tcp_shifted_skb() for FACK TCP senders. The lost_cnt_hint adjustment
in tcp_sacktag_one() only applies to non-FACK senders, so FACK senders
need their own adjustment.
This applies the spirit of 1e5289e121372a3494402b1b131b41bfe1cf9b7f -
except now that the sequence range passed into tcp_sacktag_one() is
correct we need only have a special case adjustment for FACK.
Signed-off-by: Neal Cardwell <ncardwell@google.com>
---
net/ipv4/tcp_input.c | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
@@ -1403,6 +1403,10 @@ static int tcp_shifted_skb(struct sock *sk, struct sk_buff *skb,BUG_ON(!pcount);+/* Adjust hint for FACK. Non-FACK is handled in tcp_sacktag_one(). */+if(tcp_is_fack(tp)&&(skb==tp->lost_skb_hint))+tp->lost_cnt_hint+=pcount;+TCP_SKB_CB(prev)->end_seq+=shifted;TCP_SKB_CB(skb)->seq+=shifted;
This commit ensures that lost_cnt_hint is correctly updated in
tcp_shifted_skb() for FACK TCP senders. The lost_cnt_hint adjustment
in tcp_sacktag_one() only applies to non-FACK senders, so FACK senders
need their own adjustment.
This applies the spirit of 1e5289e121372a3494402b1b131b41bfe1cf9b7f -
except now that the sequence range passed into tcp_sacktag_one() is
correct we need only have a special case adjustment for FACK.
Signed-off-by: Neal Cardwell <ncardwell@google.com>
This commit ensures that lost_cnt_hint is correctly updated in
tcp_shifted_skb() for FACK TCP senders. The lost_cnt_hint adjustment
in tcp_sacktag_one() only applies to non-FACK senders, so FACK senders
need their own adjustment.
This applies the spirit of 1e5289e121372a3494402b1b131b41bfe1cf9b7f -
except now that the sequence range passed into tcp_sacktag_one() is
correct we need only have a special case adjustment for FACK.
Signed-off-by: Neal Cardwell <ncardwell@google.com>
Applied, and queued up for -stable, thanks Neil.
There has been lots of TCP related warnings posted recently to netdev.
Finding out which of these three recent changes caused which warning and
if they're all cured by the full series is bit challenging. ...IMHO we
should wait a bit more until these recent fixes are put to stable in order
to verify that the dust has really settled.
--
i.
This commit ensures that lost_cnt_hint is correctly updated in
tcp_shifted_skb() for FACK TCP senders. The lost_cnt_hint adjustment
in tcp_sacktag_one() only applies to non-FACK senders, so FACK senders
need their own adjustment.
This applies the spirit of 1e5289e121372a3494402b1b131b41bfe1cf9b7f -
except now that the sequence range passed into tcp_sacktag_one() is
correct we need only have a special case adjustment for FACK.
Signed-off-by: Neal Cardwell <ncardwell@google.com>
Applied, and queued up for -stable, thanks Neil.
There has been lots of TCP related warnings posted recently to netdev.
Finding out which of these three recent changes caused which warning and
if they're all cured by the full series is bit challenging. ...IMHO we
should wait a bit more until these recent fixes are put to stable in order
to verify that the dust has really settled.
Yes, I agree that it would make sense to hold off on adding these
three 3.3-rc4 commits to the stable tree:
cc9a672ee522d4805495b98680f4a3db5d0a0af9
daef52bab1fd26e24e8e9578f8fb33ba1d0cb412
0af2a0d0576205dda778d25c6c344fc6508fc81d
It would make sense to let the dust settle a bit more before adding
those to the stable tree.
The same goes for the http://patchwork.ozlabs.org/patch/143114/ patch
(under review) that is in the same area of the code.
neal
On Mon, Feb 27, 2012 at 6:43 PM, Ilpo Järvinen
[off-list ref] wrote:
...Grr, I picked up Greg's new address but ended still using his old one.
The correct is one now added.
On Tue, 28 Feb 2012, Ilpo Järvinen wrote:
This commit ensures that lost_cnt_hint is correctly updated in
tcp_shifted_skb() for FACK TCP senders. The lost_cnt_hint adjustment
in tcp_sacktag_one() only applies to non-FACK senders, so FACK senders
need their own adjustment.
This applies the spirit of 1e5289e121372a3494402b1b131b41bfe1cf9b7f -
except now that the sequence range passed into tcp_sacktag_one() is
correct we need only have a special case adjustment for FACK.
Signed-off-by: Neal Cardwell <ncardwell@google.com>
Applied, and queued up for -stable, thanks Neil.
There has been lots of TCP related warnings posted recently to netdev.
Finding out which of these three recent changes caused which warning and
if they're all cured by the full series is bit challenging. ...IMHO we
should wait a bit more until these recent fixes are put to stable in order
to verify that the dust has really settled.
Yes, I agree that it would make sense to hold off on adding these
three 3.3-rc4 commits to the stable tree:
cc9a672ee522d4805495b98680f4a3db5d0a0af9
daef52bab1fd26e24e8e9578f8fb33ba1d0cb412
0af2a0d0576205dda778d25c6c344fc6508fc81d
It would make sense to let the dust settle a bit more before adding
those to the stable tree.
The same goes for the http://patchwork.ozlabs.org/patch/143114/ patch
(under review) that is in the same area of the code.
I totally disagree and I have submitted those fixes to -stable
already and do not plan to rescind those submissions at all.
Yes, I agree that it would make sense to hold off on adding these
three 3.3-rc4 commits to the stable tree:
cc9a672ee522d4805495b98680f4a3db5d0a0af9
daef52bab1fd26e24e8e9578f8fb33ba1d0cb412
0af2a0d0576205dda778d25c6c344fc6508fc81d
It would make sense to let the dust settle a bit more before adding
those to the stable tree.
The same goes for the http://patchwork.ozlabs.org/patch/143114/ patch
(under review) that is in the same area of the code.
I totally disagree and I have submitted those fixes to -stable
already and do not plan to rescind those submissions at all.
OK, sounds good to me. In that case I think it would be good to have
the http://patchwork.ozlabs.org/patch/143114/ patch in -stable as
well, since having just the three patches above would leave us with a
known reordering issue.
neal
Yes, I agree that it would make sense to hold off on adding these
three 3.3-rc4 commits to the stable tree:
cc9a672ee522d4805495b98680f4a3db5d0a0af9
daef52bab1fd26e24e8e9578f8fb33ba1d0cb412
0af2a0d0576205dda778d25c6c344fc6508fc81d
It would make sense to let the dust settle a bit more before adding
those to the stable tree.
The same goes for the http://patchwork.ozlabs.org/patch/143114/ patch
(under review) that is in the same area of the code.
I totally disagree and I have submitted those fixes to -stable
already and do not plan to rescind those submissions at all.
OK, sounds good to me. In that case I think it would be good to have
the http://patchwork.ozlabs.org/patch/143114/ patch in -stable as
well, since having just the three patches above would leave us with a
known reordering issue.
I'll make sure it hits the -stable release after the one Greg is
trying to put out right now.
The change you reference rarely matters as most of the time it passes
a degreee of reordering of one.
On Mon, Feb 27, 2012 at 11:31 PM, David Miller [off-list ref] wrote:
quoted
OK, sounds good to me. In that case I think it would be good to have
the http://patchwork.ozlabs.org/patch/143114/ patch in -stable as
well, since having just the three patches above would leave us with a
known reordering issue.
I'll make sure it hits the -stable release after the one Greg is
trying to put out right now.
Great. Thanks!
The change you reference rarely matters as most of the time it passes
a degreee of reordering of one.