Messages in this thread Patch in this message | | | Date | Mon, 20 Sep 1999 20:16:22 +0200 (CEST) | From | Andrea Arcangeli <> | Subject | Re: [patch] __lock_sock race condition in 2.3.18* |
| |
On Mon, 20 Sep 1999 kuznet@ms2.inr.ac.ru wrote:
>sk->lock.users cannot change its value under spin lock, >so that position of the check is not essential.
Woops, I missed that. If so I propose also this incremental patch to improve the scalability of the code:
--- 2.3.18ac6/include/net/sock.h Mon Sep 20 18:06:40 1999 +++ /tmp/sock.h Mon Sep 20 20:10:49 1999 @@ -672,8 +672,8 @@ (__sk)->lock.users = 0; \ if ((__sk)->backlog.tail != NULL) \ __release_sock(__sk); \ - wake_up(&((__sk)->lock.wq)); \ spin_unlock_bh(&((__sk)->lock.slock)); \ + wake_up(&((__sk)->lock.wq)); \ } while(0) /* BH context may only use the following locking interface. */
There must be a (SMP) race somewhere as I had a soft deadlock with process hanging in these three functions:
c016d09b <tcp_listen_wlock+1a7/254> c0164ec1 <tcp_data_wait+1b9/274> c0154527 <__lock_sock+16f/1fc>
Now I believe the race is in the tcp_lhash_* things but I had a look at them and I couldn't find anything wrong. I'll try again...
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/
| |