lkml.org 
[lkml]   [1999]   [May]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
Subjectnamed getting stuck in tcp_close (2.2.5-ac1, 2.2.6-ac1-ank1)
I managed to trace the "named getting stuck in tcp_close" problem a bit
further, as it just happened again.

The WCHAN shows the process blocking at tcp_close+505(decimal):

0xc0167048 <tcp_close+428>: cli
0xc0167049 <tcp_close+429>: movl (%edx),%eax
0xc016704b <tcp_close+431>: testl %eax,%eax
0xc016704d <tcp_close+433>: jne 0xc0167052 <tcp_close+438>
0xc016704f <tcp_close+435>: leal 0xfffffffc(%edx),%eax
0xc0167052 <tcp_close+438>: movl %eax,0x18(%esp,1)
0xc0167056 <tcp_close+442>: leal 0x14(%esp,1),%edi
0xc016705a <tcp_close+446>: movl %edi,(%edx)
0xc016705c <tcp_close+448>: pushl %ecx
0xc016705d <tcp_close+449>: popf
0xc016705e <tcp_close+450>: leal 0x30(%esi),%eax
0xc0167061 <tcp_close+453>: decl 0x30(%esi)
0xc0167064 <tcp_close+456>: sete %al
0xc0167067 <tcp_close+459>: testb %al,%al
0xc0167069 <tcp_close+461>: je 0xc0167074 <tcp_close+472>
0xc016706b <tcp_close+463>: pushl %esi
0xc016706c <tcp_close+464>: call 0xc01577fc <__release_sock>
0xc0167071 <tcp_close+469>: addl $0x4,%esp
0xc0167074 <tcp_close+472>: movl $0x1,(%ebx)
0xc016707a <tcp_close+478>: movb 0x28(%esi),%al
0xc016707d <tcp_close+481>: movzbl %al,%ecx
0xc0167080 <tcp_close+484>: movl $0x1,%eax
0xc0167085 <tcp_close+489>: shll %cl,%eax
0xc0167087 <tcp_close+491>: testl $0xa10,%eax
0xc016708c <tcp_close+496>: je 0xc01670a1 <tcp_close+517>
0xc016708e <tcp_close+498>: movl %ebp,%eax
0xc0167090 <tcp_close+500>: call 0xc010fcb8 <schedule_timeout>
0xc0167095 <tcp_close+505>: movl %eax,%ebp
0xc0167097 <tcp_close+507>: cmpl $0x0,0x8(%ebx)
0xc016709b <tcp_close+511>: jne 0xc01670a1 <tcp_close+517>
0xc016709d <tcp_close+513>: testl %ebp,%ebp
0xc016709f <tcp_close+515>: jne 0xc0167074 <tcp_close+472>
0xc01670a1 <tcp_close+517>: movl $0x0,(%ebx)
0xc01670a7 <tcp_close+523>: leal 0x14(%esp,1),%ebx
0xc01670ab <tcp_close+527>: pushf
0xc01670ac <tcp_close+528>: popl %ebp

...which appears to be at the only schedule_timeout call in tcp_close():

if (timeout) {
struct task_struct *tsk = current;
struct wait_queue wait = { tsk, NULL };

add_wait_queue(sk->sleep, &wait);
release_sock(sk);

while (1) {
tsk->state = TASK_INTERRUPTIBLE;
if (!closing(sk))
break;
timeout = schedule_timeout(timeout);
if (signal_pending(tsk) || !timeout)
break;
}

tsk->state = TASK_RUNNING;
remove_wait_queue(sk->sleep, &wait);

lock_sock(sk);
}

This seems to be causing the blocking. "netstat -a -n -o" output when the
process was blocking:

Active Internet connections (including servers)
Proto Recv-Q Send-Q Local Address Foreign Address State Timer
tcp 0 0 204.174.223.1:22 204.174.223.18:1020 ESTABLISHED off (0.00/0)
tcp 0 0 204.174.223.1:22 204.174.223.18:1021 ESTABLISHED off (0.00/0)
tcp 28 0 204.174.223.1:53 204.174.223.2:4743 ESTABLISHED off (0.00/0)
tcp 33 0 204.174.223.1:53 204.174.223.2:4685 ESTABLISHED off (0.00/0)
tcp 32 0 204.174.223.1:53 199.45.67.160:34067 ESTABLISHED off (0.00/0)
tcp 32 0 204.174.223.1:53 204.174.223.2:4597 CLOSE_WAIT off (0.00/0)
tcp 30 0 204.174.223.1:53 204.174.223.2:4540 CLOSE_WAIT off (0.00/0)
tcp 0 1 204.174.223.1:53 206.191.253.3:1842 LAST_ACK on (34.19/8)
tcp 0 0 204.174.223.1:2791 10.10.10.240:424 ESTABLISHED off (0.00/0)
tcp 0 0 0.0.0.0:110 0.0.0.0:* LISTEN off (0.00/0)
tcp 0 0 209.153.213.3:53 0.0.0.0:* LISTEN off (0.00/0)
tcp 0 0 204.174.223.1:53 0.0.0.0:* LISTEN off (0.00/0)
tcp 0 0 127.0.0.1:53 0.0.0.0:* LISTEN off (0.00/0)
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN off (0.00/0)
tcp 0 0 0.0.0.0:2049 0.0.0.0:* LISTEN off (0.00/0)
tcp 0 0 0.0.0.0:671 0.0.0.0:* LISTEN off (0.00/0)
tcp 0 0 0.0.0.0:37 0.0.0.0:* LISTEN off (0.00/0)
tcp 0 0 0.0.0.0:111 0.0.0.0:* LISTEN off (0.00/0)
(*snip non-tcp stuff*)
udp 65440 0 204.174.223.1:53 0.0.0.0:* off (0.00/0) 0
(*snip more*)

I did a "ps auxwl | grep named ; netstat -a -n -o | grep 206.191.253.3:1842"
continuously at the shell until the timeout number reached 0, and the
connection disappeared and the named process continued (showed
WCHAN "do_select") as normal.

So, I guess the question here is should close() be blocking on this
socket? Is this a bug in the kernel or in named?

Simon-

| Simon Kirby | Systems Administration |
| mailto:sim@netnation.com | NetNation Communications |
| http://www.netnation.com/ | Tech: (604) 684-6892 |


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

\
 
 \ /
  Last update: 2005-03-22 13:51    [W:0.052 / U:0.480 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site