From: minoura@valinux.co.jp (Minoura Makoto)
Subject: [PATCH] deadlock/panic in increasing/decreasing nfsd
Date: Wed, 10 Apr 2002 14:52:59 +0900
Sender: nfs-admin@lists.sourceforge.net
Message-ID: <20020410055259.0029619F26B@brer.local.valinux.co.jp>
Mime-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya")
Content-Type: text/plain; charset=US-ASCII
To: nfs@lists.sourceforge.net
Errors-To: nfs-admin@lists.sourceforge.net


The following patch for 2.5.7 fixes a problem that it can sleep with
a spinlock(_bh) grabbed.  This may cause a deadlock or kernel panic
when you try to increase/decrease the number of nfsd kernel threads.

I think lock_sock is not necessary in current implementation of the
network stack; for safety, we have to do this in some other way.

-- 
Minoura Makoto <minoura@valinux.co.jp>
Engineering Dept., VA Linux Systems Japan

--- net/sunrpc/svcsock.c.orig	Wed Mar 27 19:14:25 2002
+++ net/sunrpc/svcsock.c	Wed Mar 27 21:24:55 2002
@@ -422,11 +422,14 @@
 	 * on not having CAP_SYS_RESOURCE or similar, we go direct...
 	 * DaveM said I could!
 	 */
-	lock_sock(sock->sk);
+	/* Previously these operations are done after locking sock->sk.
+	 * However we are holding the spinlock serv->sv_locked, and
+	 * lock_sock() may sleep, this caused deadlock or kernel panic.
+	 * I believe removing this lock is safe in current TCP implementation.
+	 */
+	sock->sk->userlocks |= SOCK_SNDBUF_LOCK|SOCK_RCVBUF_LOCK;
 	sock->sk->sndbuf = snd * 2;
 	sock->sk->rcvbuf = rcv * 2;
-	sock->sk->userlocks |= SOCK_SNDBUF_LOCK|SOCK_RCVBUF_LOCK;
-	release_sock(sock->sk);
 #endif
 }
 /*

_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs