From: Baruch Even <baruch@ev-en.org>
To: Stephen Hemminger <shemminger@linux-foundation.org>
Cc: netdev@vger.kernel.org, "David S. Miller" <davem@davemloft.net>,
Stephen Hemminger <shemminger@osdl.org>
Subject: Re: [PATCH] Fix sorting of SACK blocks
Date: Thu, 25 Jan 2007 21:08:28 +0200 [thread overview]
Message-ID: <20070125190828.GC22455@galon.ev-en.org> (raw)
In-Reply-To: <20070125103610.4cf616a6@freekitty>
* Stephen Hemminger <shemminger@linux-foundation.org> [070125 20:47]:
> On Thu, 25 Jan 2007 20:29:03 +0200
> Baruch Even <baruch@ev-en.org> wrote:
>
> > The sorting of SACK blocks actually munges them rather than sort, causing the
> > TCP stack to ignore some SACK information and breaking the assumption of
> > ordered SACK blocks after sorting.
> >
> > The sort takes the data from a second buffer which isn't moved causing
> > subsequent data moves to occur from the wrong location. The fix is to
> > use a temporary buffer as a normal sort does.
> >
> > Signed-Off-By: Baruch Even <baruch@ev-en.org>
> >
> > diff -X 2.6-rc6/Documentation/dontdiff -ur 2.6-rc6/net/ipv4/tcp_input.c 2.6-mod/net/ipv4/tcp_input.c
> > --- 2.6-rc6/net/ipv4/tcp_input.c 2007-01-25 19:04:20.000000000 +0200
> > +++ 2.6-mod/net/ipv4/tcp_input.c 2007-01-25 19:52:04.000000000 +0200
> > @@ -1011,10 +1011,11 @@
> > for (j = 0; j < i; j++){
> > if (after(ntohl(sp[j].start_seq),
> > ntohl(sp[j+1].start_seq))){
> > - sp[j].start_seq = htonl(tp->recv_sack_cache[j+1].start_seq);
> > - sp[j].end_seq = htonl(tp->recv_sack_cache[j+1].end_seq);
> > - sp[j+1].start_seq = htonl(tp->recv_sack_cache[j].start_seq);
> > - sp[j+1].end_seq = htonl(tp->recv_sack_cache[j].end_seq);
> > + struct tcp_sack_block_wire tmp;
> > +
> > + tmp = sp[j];
> > + sp[j] = sp[j+1];
> > + sp[j+1] = tmp;
> > }
> >
> > }
>
> This looks okay, but is there a test case that can be run?
There is nothing visible that shows the problem, the only option is to
add some code to print the SACK blocks after sorting and run it over a
large BDP connection that can be saturated. You'll obviously need to
have several holes, I believe that the bug will be visible when you have
ACK packets with three SACK blocks where the first block is the highest
which should be the normal case.
Cheers,
Baruch
next prev parent reply other threads:[~2007-01-25 19:08 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-01-25 18:29 [PATCH] Fix sorting of SACK blocks Baruch Even
2007-01-25 18:36 ` Stephen Hemminger
2007-01-25 19:08 ` Baruch Even [this message]
2007-01-25 21:34 ` David Miller
2007-01-25 23:55 ` David Miller
2007-01-26 6:40 ` Baruch Even
2007-01-26 8:42 ` David Miller
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20070125190828.GC22455@galon.ev-en.org \
--to=baruch@ev-en.org \
--cc=davem@davemloft.net \
--cc=netdev@vger.kernel.org \
--cc=shemminger@linux-foundation.org \
--cc=shemminger@osdl.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).