Messages in this thread | | | Date | Thu, 2 Apr 1998 22:49:07 +0100 (IST) | From | Mark Stacey <> | Subject | tcp_v4_rehash and oops in tcp_good_socknum (2.0.32) (fwd) |
| |
Must the tcp_v4_rehash function be called everytime there is a state change?
And whenever the state moves from CLOSED to SYN_SENT, tcp_v4_hash called? and from LAST_ACK or TIME_WAIT to CLOSED, tcp_v4_unhash?
The reason I'm asking is that in my T/TCP project, I've had to modify the TCP/IP state diagram somewhat, but I'm getting an oops in the tcp_good_socknum() function. I've tracked it down to the following line:
do { sk = sk->bind_next; } while (++j < size && sk);
in particular " sk = sk->bind_next ". I think that the problem may be that I'm not unhashing the socket probably. I've displayed the sk address when the problem occurs, and I've found that its always been a socket that was used previously as a client side socket and was closed off. I appreciate that you don't have my kernel modifications handy but I should have them out soon.
Here's the oops, the two sk addresses are the sk and then the sk->bind_next. sk [00af2810] was used previously and was closed. I don't know what happens to its bind_next value and why its getting corrupted.
TTCP: sk [00af2810] TTCP: sk [0809d918] Unable to handle kernel paging request at virtual address c809d984 current->tss.cr3 = 00cd2000, 8r3 = 00cd2000 *pde = 00000000 Oops: 0000 CPU: 0 EIP: 0010:[tcp_good_socknum+207/576] EFLAGS: 00010202 eax: 00000015 ebx: 0809d918 ecx: 0018e754 edx: 00d84c0c esi: 00000000 edi: 00000010 ebp: 00007fff esp: 00cdde6c ds: 0018 es: 0018 fs: 002b gs: 002b ss: 0018 Process initial_client (pid: 316, process nr: 39, stackpage=00cdd000) Stack: 00181602 0809d918 00cdb810 00000020 00000000 00000013 00000001 00000000 00000050 00000000 0014ea96 00cdb810 0014f756 00cdb810 00cddf00 00d59e90 006b38c4 00000013 00136a4d 00d59e90 00cddee4 00000013 00000000 00000020 Call Trace: [inet_autobind+30/156] [inet_sendmsg+122/172] [sys_sendto+317/344] [sk_alloc+16/48] [do_no_page+259/808] [do_no_page+391/808] [do_no_page+0/808] [sys_socketcall+495/732] [system_call+85/128] Code: 8b 5b 6c 83 c4 08 8b 54 24 10 42 39 ea 7d 1c 85 db 75 de 89 Aiee, killing interrupt handler
Mark Stacey
... and that's my two cents.
"Its not that I forgot, its just that I can't remember"
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu
| |