netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [TCP]: fack_counts more fixes (the previous ones were incomplete)
@ 2007-12-11 11:43 Ilpo Järvinen
  2007-12-11 12:15 ` David Miller
  0 siblings, 1 reply; 2+ messages in thread
From: Ilpo Järvinen @ 2007-12-11 11:43 UTC (permalink / raw)
  To: David Miller; +Cc: Netdev, Reuben Farrelly, Andrew Morton

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1959 bytes --]

Noticed later on that the things are still somewhat broken. Here's yet 
another fix to that same function. In addition, I'll do later on a patch 
to remove the __-version altogether.

-- 
 i.

--
[PATCH] [TCP]: fack_counts more fixes (the previous ones were incomplete)

1) Prev NULL check should also dereference

2) The loop reorganization did make things only slightly better,
   just changing the same not-updated problem to occur in
   another scenario. And I also noticed that in worst case it
   would be an infinite loop (could do that also before the
   change), but it required losses in the same window when TCP
   runs out new data. Now check really against the list heads
   rather than a valid skb which should still be processed.

Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi>
---
 include/net/tcp.h |    6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/include/net/tcp.h b/include/net/tcp.h
index 11a7e3e..2d9949e 100644
--- a/include/net/tcp.h
+++ b/include/net/tcp.h
@@ -1474,7 +1474,7 @@ static inline struct sk_buff *__tcp_reset_fack_counts(struct sock *sk,
 {
 	unsigned int fc = 0;
 
-	if (prev != NULL)
+	if (*prev != NULL)
 		fc = TCP_SKB_CB(*prev)->fack_count + tcp_skb_pcount(*prev);
 
 	BUG_ON((*prev != NULL) && !tcp_skb_adjacent(sk, *prev, skb));
@@ -1531,7 +1531,7 @@ static inline void tcp_reset_fack_counts(struct sock *sk, struct sk_buff *inskb)
 		skb[otherq] = prev->next;
 	}
 
-	do {
+	while (skb[queue] != (struct sk_buff *)__tcp_list_select(sk, queue)) {
 		/* Lazy find for the other queue */
 		if (skb[queue] == NULL) {
 			skb[queue] = tcp_write_queue_find(sk, TCP_SKB_CB(prev)->seq,
@@ -1545,7 +1545,7 @@ static inline void tcp_reset_fack_counts(struct sock *sk, struct sk_buff *inskb)
 			break;
 
 		queue ^= TCP_WQ_SACKED;
-	} while (skb[queue] != __tcp_write_queue_tail(sk, queue));
+	}
 }
 
 static inline void __tcp_insert_write_queue_after(struct sk_buff *skb,
-- 
1.5.0.6

^ permalink raw reply related	[flat|nested] 2+ messages in thread

* Re: [TCP]: fack_counts more fixes (the previous ones were incomplete)
  2007-12-11 11:43 [TCP]: fack_counts more fixes (the previous ones were incomplete) Ilpo Järvinen
@ 2007-12-11 12:15 ` David Miller
  0 siblings, 0 replies; 2+ messages in thread
From: David Miller @ 2007-12-11 12:15 UTC (permalink / raw)
  To: ilpo.jarvinen; +Cc: netdev, reuben-linuxkernel, akpm

From: "Ilpo_Järvinen" <ilpo.jarvinen@helsinki.fi>
Date: Tue, 11 Dec 2007 13:43:24 +0200 (EET)

> [PATCH] [TCP]: fack_counts more fixes (the previous ones were incomplete)
> 
> 1) Prev NULL check should also dereference
> 
> 2) The loop reorganization did make things only slightly better,
>    just changing the same not-updated problem to occur in
>    another scenario. And I also noticed that in worst case it
>    would be an infinite loop (could do that also before the
>    change), but it required losses in the same window when TCP
>    runs out new data. Now check really against the list heads
>    rather than a valid skb which should still be processed.
> 
> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi>

Applied, thanks Ilpo.

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2007-12-11 12:15 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2007-12-11 11:43 [TCP]: fack_counts more fixes (the previous ones were incomplete) Ilpo Järvinen
2007-12-11 12:15 ` David Miller

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).