Re: Spinlocking patch for in xprt.c

2001-01-14 Thread Trond Myklebust 

> " " == David S Miller <[EMAIL PROTECTED]> writes:

 > Trond, did you actually look at how this code works before you
 > made modifications to my fixes?

 > xprt_lock serializes sleep/wakeup sequences in the xprt code,
 > so you cannot remove xprt_lock from the sections where I added
 > holding of xprt_sock_lock to protect the state of
 > xprt->snd_task.  So for example, this part of your patch is
 > completely bogus and will create new corruptions and crashes:

IIRC xprt_lock is there for 2 purposes:

  - serialize access to the TCP connect code
  - gate access to the *socket* via the xprt_(up|down)_transmit() (and
hence setting xprt->snd_task which is a pointer to the task that
currently is allowed to access the socket.)

Those 2 tasks are completely orthogonal to one another, so we should
be quite free to drop xprt_lock in the second case.

I can see no other places where we're using xprt_lock to protect a
sleep/wakeup of xprt->snd_task unless you're introducing it? If so for
what purpose?

Cheers,
  Trond
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Spinlocking patch for in xprt.c

2001-01-14 Thread Trond Myklebust 

 " " == David S Miller [EMAIL PROTECTED] writes:

  Trond, did you actually look at how this code works before you
  made modifications to my fixes?

  xprt_lock serializes sleep/wakeup sequences in the xprt code,
  so you cannot remove xprt_lock from the sections where I added
  holding of xprt_sock_lock to protect the state of
  xprt-snd_task.  So for example, this part of your patch is
  completely bogus and will create new corruptions and crashes:

IIRC xprt_lock is there for 2 purposes:

  - serialize access to the TCP connect code
  - gate access to the *socket* via the xprt_(up|down)_transmit() (and
hence setting xprt-snd_task which is a pointer to the task that
currently is allowed to access the socket.)

Those 2 tasks are completely orthogonal to one another, so we should
be quite free to drop xprt_lock in the second case.

I can see no other places where we're using xprt_lock to protect a
sleep/wakeup of xprt-snd_task unless you're introducing it? If so for
what purpose?

Cheers,
  Trond
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Spinlocking patch for in xprt.c

2001-01-13 Thread David S. Miller 


Trond, did you actually look at how this code works before
you made modifications to my fixes?

xprt_lock serializes sleep/wakeup sequences in the xprt code, so you
cannot remove xprt_lock from the sections where I added holding of
xprt_sock_lock to protect the state of xprt->snd_task.  So for
example, this part of your patch is completely bogus and will create
new corruptions and crashes:

@@ -1143,10 +1143,10 @@
struct rpc_xprt *xprt = task->tk_rqstp->rq_xprt;
 
if (xprt->snd_task && xprt->snd_task == task) {
-   spin_lock(_lock);
+   spin_lock_bh(_sock_lock);
xprt->snd_task = NULL;
rpc_wake_up_next(>sending);
-   spin_unlock(_lock);
+   spin_unlock_bh(_sock_lock);
}
 }

You _must_ hold both xprt_lock and xprt_sock_lock in this
section of code, not just one or just the other.

Linus, please do not apply this patch until these issues
are addressed.

Later,
David S. Miller
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Spinlocking patch for in xprt.c

2001-01-13 Thread David S. Miller 


Trond, did you actually look at how this code works before
you made modifications to my fixes?

xprt_lock serializes sleep/wakeup sequences in the xprt code, so you
cannot remove xprt_lock from the sections where I added holding of
xprt_sock_lock to protect the state of xprt-snd_task.  So for
example, this part of your patch is completely bogus and will create
new corruptions and crashes:

@@ -1143,10 +1143,10 @@
struct rpc_xprt *xprt = task-tk_rqstp-rq_xprt;
 
if (xprt-snd_task  xprt-snd_task == task) {
-   spin_lock(xprt_lock);
+   spin_lock_bh(xprt_sock_lock);
xprt-snd_task = NULL;
rpc_wake_up_next(xprt-sending);
-   spin_unlock(xprt_lock);
+   spin_unlock_bh(xprt_sock_lock);
}
 }

You _must_ hold both xprt_lock and xprt_sock_lock in this
section of code, not just one or just the other.

Linus, please do not apply this patch until these issues
are addressed.

Later,
David S. Miller
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/