> > > > +++ 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
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxx. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href