Re: [PATCH] NLM: hold BKL when clearing global lockd task and serv vars

[Tom Tucker <tom@opengridcomputing.com>]

On Mon, 2008-04-07 at 13:56 -0400, J. Bruce Fields wrote:
> On Mon, Apr 07, 2008 at 12:45:01PM -0400, Christoph Hellwig wrote:
> > On Mon, Apr 07, 2008 at 09:38:34AM -0400, Jeff Layton wrote:
> > > The global task and serv pointers for lockd are normally protected by
> > > the nlmsvc_mutex. The exception is when the lockd exits abnormally. When
> > > this occurs, these variables are cleared without any locking.
> > 
> > Shouldn't we get rid of the case where it exits abnormally instead?
> 
> I tried to figure out when this could actually occur (when can
> svc_recv() return an error other than -EINTR or -EAGAIN?), and got lost
> in sock_recvmsg():
> 
> 	- svc_recv() itself returns only -EAGAIN or the return from
> 	  ->xpo_recvfrom().
> 	- the only xpo_recvfrom() that's interesting is
> 	  svc_tcp_recvfrom(), which can return the error it gets from
> 	  svc_recvfrom(), which can return the error from
> 	  kernel_recvmsg(), which gets its return from sock_recvmsg().
> 
> Since __sock_recvmsg() has a security hook, it looks like we can end up
> with an -EACCES from selinux?

FWIW: I believe that if svc_recv returns anything other then -EINTR or
-EAGAIN, the service thread exits. I believe that the current design
(could be broken) is that if the transport finds an error, the action is
to set the XPT_CLOSE bit, enqueue the transport and return -EAGAIN. This
will cause the service thread to call svc_recv again and close
processing to occur.

> 
> So one case would be selinux deciding we weren't allowed to receive
> packets from this socket.  Huh.
> 
> --b.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html