[BUG?] tcp: potential bug in tcp_is_sackblock_valid()

Hi all,

I found a check in tcp_is_sackblock_valid() is suspicious. It against
its comment and RFC. I think the correct check should be:

---

diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index 385c470..a5d01b1 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c

@@ -1124,7 +1124,7 @@ static int tcp_is_sackblock_valid(struct tcp_sock *tp, int is_dsack,
                return 0;
 
        /* ...Then it's D-SACK, and must reside below snd_una completely */
-       if (!after(end_seq, tp->snd_una))
+       if (after(end_seq, tp->snd_una))
                return 0;
 
        if (!before(start_seq, tp->undo_marker))
---

I also checked /proc/net/netstat of my laptop, found TCPDSACKIgnoredOld
field is not zero. Maybe it's caused by the bug.

Regards
Yan, Zheng

On Fri, Sep 09, 2011 at 09:45:52AM +0800, Yan, Zheng wrote:

Yes this looks like a typo.  Please resend your patch with a
description and signed-off-by line.

Thanks,
-- 
Email: Herbert Xu [off-list ref]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

On 09/09/2011 09:54 AM, Herbert Xu wrote:

On Fri, Sep 09, 2011 at 09:45:52AM +0800, Yan, Zheng wrote:

quoted

Hi all,

I found a check in tcp_is_sackblock_valid() is suspicious. It against
its comment and RFC. I think the correct check should be:

---

diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index 385c470..a5d01b1 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c

@@ -1124,7 +1124,7 @@ static int tcp_is_sackblock_valid(struct tcp_sock *tp, int is_dsack,
                return 0;
 
        /* ...Then it's D-SACK, and must reside below snd_una completely */
-       if (!after(end_seq, tp->snd_una))
+       if (after(end_seq, tp->snd_una))
                return 0;
 
        if (!before(start_seq, tp->undo_marker))
---

I also checked /proc/net/netstat of my laptop, found TCPDSACKIgnoredOld
field is not zero. Maybe it's caused by the bug.

Yes this looks like a typo.  Please resend your patch with a
description and signed-off-by line.

I think the bug has a big influence on tcp DSACKs. It's better to
leave it to people who fully understand tcp code.

Thanks.

On Fri, 9 Sep 2011, Yan, Zheng wrote:

On 09/09/2011 09:54 AM, Herbert Xu wrote:

quoted

On Fri, Sep 09, 2011 at 09:45:52AM +0800, Yan, Zheng wrote:

quoted

I found a check in tcp_is_sackblock_valid() is suspicious. It against
its comment and RFC. I think the correct check should be:
---

diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index 385c470..a5d01b1 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c

@@ -1124,7 +1124,7 @@ static int tcp_is_sackblock_valid(struct tcp_sock *tp, int is_dsack,
                return 0;
 
        /* ...Then it's D-SACK, and must reside below snd_una completely */
-       if (!after(end_seq, tp->snd_una))
+       if (after(end_seq, tp->snd_una))
                return 0;
 
        if (!before(start_seq, tp->undo_marker))
---

I also checked /proc/net/netstat of my laptop, found TCPDSACKIgnoredOld
field is not zero. Maybe it's caused by the bug.

Hmm, some Ignored I was expecting to see even when nothing was wrong but I 
think it might have been the other counter... too long time already passed 
to remember all the details I've been thinking.

quoted

Yes this looks like a typo.  Please resend your patch with a
description and signed-off-by line.

I think the bug has a big influence on tcp DSACKs. It's better to
leave it to people who fully understand tcp code.

Indeed, it looks like a double negative error.

-- 
 i.

Le vendredi 09 septembre 2011 à 09:45 +0800, Yan, Zheng a écrit :

Acked-by: Eric Dumazet <redacted>

This bug was introduced in 2.6.24 by commit 5b3c9882

From: Eric Dumazet <redacted>
Date: Sun, 18 Sep 2011 21:35:44 +0200

Le vendredi 09 septembre 2011 à 09:45 +0800, Yan, Zheng a écrit :

quoted

Hi all,

I found a check in tcp_is_sackblock_valid() is suspicious. It against
its comment and RFC. I think the correct check should be:

---

diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index 385c470..a5d01b1 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c

@@ -1124,7 +1124,7 @@ static int tcp_is_sackblock_valid(struct tcp_sock *tp, int is_dsack,
                return 0;
 
        /* ...Then it's D-SACK, and must reside below snd_una completely */
-       if (!after(end_seq, tp->snd_una))
+       if (after(end_seq, tp->snd_una))
                return 0;
 
        if (!before(start_seq, tp->undo_marker))

---

Acked-by: Eric Dumazet <redacted>

This bug was introduced in 2.6.24 by commit 5b3c9882

Yan, please repost this patch with proper commit message and signoffs
so I can apply it, thanks.

D-SACK is allowed to reside below snd_una. But the corresponding check
in tcp_is_sackblock_valid() is the exact opposite. It looks like a typo.

Signed-off-by: Zheng Yan <redacted>
Acked-by: Eric Dumazet <redacted>
---

diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index ea0d218..21fab3e 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c

@@ -1124,7 +1124,7 @@ static int tcp_is_sackblock_valid(struct tcp_sock *tp, int is_dsack,
 		return 0;
 
 	/* ...Then it's D-SACK, and must reside below snd_una completely */
-	if (!after(end_seq, tp->snd_una))
+	if (after(end_seq, tp->snd_una))
 		return 0;
 
 	if (!before(start_seq, tp->undo_marker))

From: "Yan, Zheng" <redacted>
Date: Mon, 19 Sep 2011 10:05:31 +0800

D-SACK is allowed to reside below snd_una. But the corresponding check
in tcp_is_sackblock_valid() is the exact opposite. It looks like a typo.

Signed-off-by: Zheng Yan <redacted>
Acked-by: Eric Dumazet <redacted>

Applied, thanks.

On 09/19/2011 04:37 AM, David Miller wrote:

quoted

D-SACK is allowed to reside below snd_una. But the corresponding check
in tcp_is_sackblock_valid() is the exact opposite. It looks like a typo.

Signed-off-by: Zheng Yan<redacted>
Acked-by: Eric Dumazet<redacted>

Applied, thanks.

Dave,

Have you also queued it up for stable as per Eric's remark that this was introduced in 2.6.24?

Sorry if this is implied in your workflow.

Thanks, Jan

From: Jan Ceuleers <redacted>
Date: Mon, 19 Sep 2011 19:29:16 +0200

Have you also queued it up for stable as per Eric's remark that this
was introduced in 2.6.24?

Yes, I have.