lkml.org 
[lkml]   [1999]   [Sep]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
Patch in this message
/
Date
From
SubjectRe: [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/

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