kernel panics at google

[David S. Miller]

   Date: Thu, 20 Jan 2000 15:58:16 +0000 (GMT)
   From: Alan Cox <alan en lxorguk.ukuu.org.uk>

   Dave: Side item tcp_retrans_try_collapse doesnt seem to care about collapsing
   in SACK'd data - is that right ?  

It refuses to coalesce SACK'd packets, as per the test:

		/* Also punt if next skb has been SACK'd. */
		if(TCP_SKB_CB(next_skb)->sacked & TCPCB_SACKED_ACKED)
			return;

skb->next being NULL is an illegal state for the write_queue,
the queue is a ring list, so the tail element must point to
the beginning of the write_queue.

   Second question: tcp_xmit_retransmit_queue is entered with
   tcp->retrans_head pointing part way into the retransmit queue if we
   baled part way through the previous retransmit run (eg cos cwnd got
   us). We guarantees that tp->retrans_head is still pointing to a
   valid packet so right now I cant see a cause.

Correct.  There are several checks for NULL, anything which
fixes it up points it at the head of the write_queue which
by definition is not empty.

All of this code is protected by asynchronous behavior either
by virtue of running in BH or from the user within' BH atomic
backlog processing.

As in many cases, we still have the ugly "kfree_skb() runs
destructor in hardware IRQ context" stuff which can mess
with socket state.  I've been over these paths several
times and they absoultely cannot mess with the socket
write queue, or retrans_head/send_head in any way.

Later,
David S. Miller
davem en redhat.com


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo en vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/