Chuck Lever wrote:
On May 20, 2008, at 5:21 PM, Trond Myklebust wrote:
On Tue, 2008-05-20 at 16:29 -0400, Chuck Lever wrote:
Making debugging output a little cleaner in call_verify by
displaying the
name of the RPC procedure instead of it's number.
Signed-off-by: Chuck Lever <chuck.lever@xxxxxxxxxx>
---
net/sunrpc/clnt.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/sunrpc/clnt.c b/net/sunrpc/clnt.c
index adbc85c..5aa32fa 100644
--- a/net/sunrpc/clnt.c
+++ b/net/sunrpc/clnt.c
@@ -1431,10 +1431,10 @@ call_verify(struct rpc_task *task)
error = -EPROTONOSUPPORT;
goto out_err;
case RPC_PROC_UNAVAIL:
- dprintk("RPC: %5u %s: proc %p unsupported by program %u, "
+ dprintk("RPC: %5u %s: proc %s unsupported by program %u, "
"version %u on server %s\n",
task->tk_pid, __func__,
- task->tk_msg.rpc_proc,
+ task->tk_msg.rpc_proc->p_name,
task->tk_client->cl_prog,
task->tk_client->cl_vers,
task->tk_client->cl_server);
This will cause a crash if you ever call it while somebody is calling
rpc_call_null. There may be other cases too.
How could you ever get an RPC_PROC_UNAVAIL with a NULL RPC?
I have seen servers which didn't implement the NULL_PROC procedure
for protocols like NFS_ACL. Beats me why.
It would be good if the client didn't crash just because someone
got lazy in the server implementation though.
ps
--
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
