On Mon, Aug 24, 2009 at 07:42:27PM -0400, Trond Myklebust wrote: > On Mon, 2009-08-24 at 19:34 -0400, J. Bruce Fields wrote: > > On Thu, Aug 20, 2009 at 03:34:23AM +0300, Benny Halevy wrote: > > > From: Rahul Iyer <iyer@xxxxxxxxxx> > > > > > > Signed-off-by: Rahul Iyer <iyer@xxxxxxxxxx> > > > Signed-off-by: Mike Sager <sager@xxxxxxxxxx> > > > Signed-off-by: Marc Eshel <eshel@xxxxxxxxxxxxxxx> > > > Signed-off-by: Benny Halevy <bhalevy@xxxxxxxxxxx> > > > Signed-off-by: Ricardo Labiaga <Ricardo.Labiaga@xxxxxxxxxx> > > > > This patch needs an ACK from Trond. > > > > > > > > When the call direction is a reply, copy the xid and call direction into the > > > req->rq_private_buf.head[0].iov_base otherwise rpc_verify_header returns > > > rpc_garbage. > > > > Looks mostly OK, though blocking the client rpciod on the > > bc_send_request method may be a problem--rpciod normally tries not to > > sleep, and the other send_request methods look like they avoid it. > > Agreed. Blocking on sending is unacceptable inside rpciod. Please either > use non-blocking I/O, or use a different thread context for this. We did some work to avoid having to spawn a thread on the server for every recall, and I'd still prefer to avoid that. But I'm not sure what's required to make the server send routine non-blocking. --b. -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html