Trivial patch, but--any objection to removing these assertions?
We set svsk->sk_pool = pool just 30-some lines above, and there's no
obvious reason this should have changed, or any other particular reason
to assert this here.
Signed-off-by: J. Bruce Fields <[email protected]>
---
net/sunrpc/svcsock.c | 2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/net/sunrpc/svcsock.c b/net/sunrpc/svcsock.c
index 12ff5da..d064879 100644
--- a/net/sunrpc/svcsock.c
+++ b/net/sunrpc/svcsock.c
@@ -298,12 +298,10 @@ svc_sock_enqueue(struct svc_sock *svsk)
atomic_inc(&svsk->sk_inuse);
rqstp->rq_reserved = serv->sv_max_mesg;
atomic_add(rqstp->rq_reserved, &svsk->sk_reserved);
- BUG_ON(svsk->sk_pool != pool);
wake_up(&rqstp->rq_wait);
} else {
dprintk("svc: socket %p put into queue\n", svsk->sk_sk);
list_add_tail(&svsk->sk_ready, &pool->sp_sockets);
- BUG_ON(svsk->sk_pool != pool);
}
out_unlock:
--
1.5.3.1.40.g6972
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
On Wed, Sep 12, 2007 at 07:43:17PM -0400, J. Bruce Fields wrote:
> Trivial patch, but--any objection to removing these assertions?
>
> We set svsk->sk_pool = pool just 30-some lines above, and there's no
> obvious reason this should have changed, or any other particular reason
> to assert this here.
Yeah, you'd think that. However we saw these BUG_ON()s tripped
when attempting to port the 2.6.18-based NFS/RDMA patches to a
2.6.19-like kernel. All it takes is for some transport code to get
confused about the proper way to clear SK_BUSY, and *blam*. So I
think they're useful.
Greg.
--
Greg Banks, R&D Software Engineer, SGI Australian Software Group.
Apparently, I'm Bedevere. Which MPHG character are you?
I don't speak for SGI.
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
On Sat, Sep 15, 2007 at 02:40:58AM +1000, Greg Banks wrote:
> On Wed, Sep 12, 2007 at 07:43:17PM -0400, J. Bruce Fields wrote:
> > Trivial patch, but--any objection to removing these assertions?
> >
> > We set svsk->sk_pool = pool just 30-some lines above, and there's no
> > obvious reason this should have changed, or any other particular reason
> > to assert this here.
>
> Yeah, you'd think that. However we saw these BUG_ON()s tripped
> when attempting to port the 2.6.18-based NFS/RDMA patches to a
> 2.6.19-like kernel. All it takes is for some transport code to get
> confused about the proper way to clear SK_BUSY, and *blam*. So I
> think they're useful.
OK, I'll take your word for it--dropped. (But, I'm just curious--do you
remember what the sequence of events was?)
--b.
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
On Fri, Sep 14, 2007 at 12:50:13PM -0400, J. Bruce Fields wrote:
> On Sat, Sep 15, 2007 at 02:40:58AM +1000, Greg Banks wrote:
> > On Wed, Sep 12, 2007 at 07:43:17PM -0400, J. Bruce Fields wrote:
> > > Trivial patch, but--any objection to removing these assertions?
> > >
> > > We set svsk->sk_pool = pool just 30-some lines above, and there's no
> > > obvious reason this should have changed, or any other particular reason
> > > to assert this here.
> >
> > Yeah, you'd think that. However we saw these BUG_ON()s tripped
> > when attempting to port the 2.6.18-based NFS/RDMA patches to a
> > 2.6.19-like kernel. All it takes is for some transport code to get
> > confused about the proper way to clear SK_BUSY, and *blam*. So I
> > think they're useful.
>
> OK, I'll take your word for it--dropped. (But, I'm just curious--do you
> remember what the sequence of events was?)
It's been a while, but IIRC the new transport code had copied out the
internals of svc_request_received() pre .19, and were manually clearing
SK_BUSY and calling svc_sock_enqueue(). In .19 when sk_pool was added,
svc_request_received() began setting sk_pool to NULL, and the transport
code wasn't doing that. Or maybe that was a different failure mode ;-)
Greg.
--
Greg Banks, R&D Software Engineer, SGI Australian Software Group.
Apparently, I'm Bedevere. Which MPHG character are you?
I don't speak for SGI.
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs