On 3/31/2007, "David Miller" [off-list ref] wrote:

From: Thomas Graf <tgraf@suug.ch>
Date: Sat, 31 Mar 2007 00:10:54 +0200

quoted

* David Miller [off-list ref] 2007-03-30 14:43

quoted

Let's not speculate, let's find out for sure if snd_una is
surpassing high_seq while we're in this state.

Andrew please give this debugging patch a spin, and also what
is your workload?  I'd like to play with it too.

I've tried to code this patch so that if the bug triggers your
machine shouldn't crash and burn completely, just spit out the
log message.

I'm running into the same bug as Andew, i was able to reproduce
using Dave's patch within minutes:

TCP BUG: high_seq==NULL [c3c9cc54] q[c3c94edc] t[c3c9cc54]

The after(snd_una, high_seq) check is not triggered.

So tp->high_seq points to the tail packet end sequence.

Ilpo does this clear things up?

Thanks for the info.

I think that the if condition before the write_queue_find should check if
skb is valid before doing after(TCP_SKB_CB(skb)->seq, tp->high_seq), it
is pointing to sk_write_queue rather than a valid skb when the previous
loop exits (there might be a similar problem later in the code too). I
apologize I cannot provide a good patch at this point of time because I
moved on Thursday and the ISP hasn't yet activated the access link
(writing this from a library machine).

--
 i.