Thread (13 messages) flat view 13 messages, 3 authors, 2011-07-07

RE: [RFC] non-preemptible kernel socket for RAMster

From: Dan Magenheimer <hidden>
Date: 2011-07-05 19:07:36
Also in: linux-mm

quoted
quoted
quoted
+++ linux-2.6.37-ramster/net/core/sock.c	2011-07-03 19:10:04.340980799 -0600
@@ -1587,6 +1587,14 @@ static void __lock_sock(struct sock *sk)
 	__acquires(&sk->sk_lock.slock)
 {
 	DEFINE_WAIT(wait);
+	if (!preemptible()) {
+		while (sock_owned_by_user(sk)) {
+			spin_unlock_bh(&sk->sk_lock.slock);
+			cpu_relax();
+			spin_lock_bh(&sk->sk_lock.slock);
+		}
+		return;
+	}
Hmm, was this tested on UP machine ?
Hi Eric --

Thanks for the reply!

I hadn't tested UP in awhile so am testing now, and it seems to
work OK so far.  However, I am just testing my socket, *not* testing
sockets in general.  Are you implying that this patch will
break (kernel) sockets in general on a UP machine?  If so,
could you be more specific as to why?  (Again, I said
I am a networking idiot. ;-)  I played a bit with adding
a new SOCK_ flag and triggering off of that, but this
version of the patch seemed much simpler.
Say you have two processes and socket S

One process locks socket S, and is preempted by another process.

This second process is non preemptible and try to lock same socket.

-> deadlock, since P1 never releases socket S
Oh, OK.  My use model is that a socket that is used non-preemptible
must always be used non-preemptible.  In other words, this kind
of socket is an extreme form of non-blocking.  Doesn't that seem
like a reasonable constraint? 

Thanks,
Dan
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help