From: Ian McDonald <[EMAIL PROTECTED]>
Date: Thu, 13 Oct 2005 16:21:27 +1300
> EIP is at ip_queue_xmit+0x14/0x4c0
...
> Code: 44 24 04 e8 6f 05 00 00 e9 e8 fe ff ff 8d 76 00 8d bc 27 00 00
> 00 00 55 57 56 53 81 ec bc 00 00 00 8b ac 24 d0 00 00 00 8b 5d 08
> <8b> 83 3c 01 00 00 89 44 24 14 8b 45 28 85 c0 89 44 24 18 0f 85
This corresponds to the beginning of ip_queue_xmit which, from Code:,
disassembles like this (with C code guesses using my novice
understanding of the x86 :-):
ip_queue_xmit:
push %ebp
push %edi
push %esi
push %ebx
sub $0xbc, %esp
mov 0xd0(%esp), %ebp ! %ebp = arg0 (skb)
mov 0x8(%ebp), %ebx ! %ebx = skb->sk
mov 0x13c(%ebx), %eax ! %eax = inet_sk(sk)->opt
We crash on that last instruction because %ebx is zero during the
load, so the problem appears to be that skb->sk is NULL.
So find out what path in the DCCP stack allows an output packet
SKB to not have skb->sk initialized. :-)
This funny buisness with only doing a skb_set_owner_w(skb, sk)
in dccp_transmit_skb() if the SKB is cloned is probably part
of the problem.
For example, the first OOPS goes back into dccp_retransmit_skb(). If
the skb is already cloned, it makes a copy using pskb_copy() and
passes that to dccp_transmit_skb(). That won't pass the
"skb_cloned()" test, and will likely leave us with a NULL skb->sk.
There needs to therefore be a better way to test "not DATA packet" in
dccp_transmit_skb(), because "skb_cloned()" obviously does not always
indicate that.
So there's your bug :-)
-
To unsubscribe from this list: send the line "unsubscribe dccp" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
