>1) locking orders... I mean between socket lock and
> lhash lock. Do you see it? I am rather certain this is a problem
> even if it is not exactly the case Andrea is seeing.
Yes. I think what happened is this:
task1 task2
----- -----
lock_sock(sk1)
tcp_get_info()
increase lhash users
lock_sock(sk1)
block
tcp_listen_wlock()
block
-> deadlock
Actually I am going to discover the exact path of task1 (the task2 path is
trivial, it's just a cat /proc/net/tcp) with this little debugging code.
--- my-2.3.18ac6/net/core/sock.c.~1~ Mon Sep 20 20:52:47 1999
+++ my-2.3.18ac6/net/core/sock.c Mon Sep 20 21:48:14 1999
@@ -757,9 +757,14 @@
add_wait_queue_exclusive(&sk->lock.wq, &wait);
for(;;) {
+ static int oops = 0;
current->state = TASK_EXCLUSIVE | TASK_UNINTERRUPTIBLE;
spin_unlock_bh(&sk->lock.slock);
- schedule();
+ if (!schedule_timeout(5*HZ) || oops)
+ {
+ oops = 1;
+ BUG();
+ }
spin_lock_bh(&sk->lock.slock);
if(!sk->lock.users)
break;
When I'll know the path of task1 I'll be able to generate a fix.
Andrea
-
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/