Closed madhanraj closed 8 years ago
I see it is a relatively old build (3.18.14). Please update to the latest and let us know if this happens again. There have been some fixes in v0.90, that probably solved this issue.
Unable to reproduce the issue . Because two context call the tcp close same time that before delete the bind_hash address, I think it is hard to reproduce again.
mptcp_sub_close_wq locking with "meta_sk" but tcp_clsoe function use different "sk" variable.
sk address = 0xFFFFFFC02A04D700
meta_sk = 0xFFFFFFC026b48740
meta_sk = 0xFFFFFFC026B48740 -> (
__sk_common = (skc_addrpair = 1016694380879476435, skc_daddr = 427095763, skc_rcv_saddr = 236717607, skc_hash = 3937733995, skc_u16hashes = (3435
sk_lock = (
slock = (rlock = (raw_lock = (owner = 77, next = 77))),
owned = 1,
wq = (lock = (rlock = (raw_lock = (owner = 0, next = 0))), task_list = (next = 0xFFFFFFC026B487C0, prev =
case TCP_CLOSE: if (oldstate == TCP_CLOSE_WAIT || oldstate == TCP_ESTABLISHED) TCP_INC_STATS(sock_net(sk), TCP_MIB_ESTABRESETS);
sk->sk_prot->unhash(sk); if (inet_csk(sk)->icsk_bind_hash && !(sk->sk_userlocks & SOCK_BINDPORT_LOCK)) inet_put_port(sk)
000 |__inet_put_port(inline) 000 |inet_put_port( | sk = 0xFFFFFFC02A04D700) | hashinfo = 0xFFFFFFC0028A6400 | head = 0xFFFFFFC878C6EC00 \ | tb = 0x0 | next = 0x0 | pprev = 0xFFFFFFC07C41BBE8
Hence this problem occurs .. Can we lock SK in the mptcp_sub_close_wq
Oh you have a coredump of this crash? That would be really useful if you could share it!
Just checking again, do you have a corefile of this crash? It would be very very valuable and would help debugging it.
duplicated issue #115
I have been using MPTCP v0.90 for stress testing . And I was hit with a kernel panic . However, I was not able to reproduce the issue . The issue looks like the tb value is NULL . which is called by mptcp_sub_close_wq