net/sunrpc/clnt.c compile fix

Not sure if anyone has submitted this already, but as the subject implies, net/sunrpc/clnt.c does not compile in either stock test7 or in current BK:

CC net/sunrpc/clnt.o
net/sunrpc/clnt.c: In function `call_verify':
net/sunrpc/clnt.c:965: structure has no member named tk_pid' net/sunrpc/clnt.c:970: structure has no member named tk_pid' net/sunrpc/clnt.c:976: structure has no member named `tk_pid' make[1]: *** [net/sunrpc/clnt.o] Error 1
make: *** [net/sunrpc/clnt.o] Error 2

This is due to the fact that tk_pid is protected by RPC_DEBUG. Wrapping through dprintk() fixes this.

@@ -961,18 +961,18 @@
 	case RPC_SUCCESS:
 		return p;
 	case RPC_PROG_UNAVAIL:
-		printk(KERN_WARNING "RPC: %4d call_verify: program %u is unsupported by server %s\n",
+		dprintk("RPC: %4d call_verify: program %u is unsupported by server %s\n",
 				task->tk_pid, (unsigned int)task->tk_client->cl_prog,
 				task->tk_client->cl_server);
 		goto out_eio;
 	case RPC_PROG_MISMATCH:
-		printk(KERN_WARNING "RPC: %4d call_verify: program %u, version %u unsupported by server %s\n",
+		dprintk("RPC: %4d call_verify: program %u, version %u unsupported by server %s\n",
 				task->tk_pid, (unsigned int)task->tk_client->cl_prog,
 				(unsigned int)task->tk_client->cl_vers,
 				task->tk_client->cl_server);
 		goto out_eio;
 	case RPC_PROC_UNAVAIL:
-		printk(KERN_WARNING "RPC: %4d call_verify: proc %p unsupported by program %u, version %u on server %s\n",
+		dprintk("RPC: %4d call_verify: proc %p unsupported by program %u, version %u on server %s\n",
 				task->tk_pid, task->tk_msg.rpc_proc,
 				task->tk_client->cl_prog,
 				task->tk_client->cl_vers,

Since it compiled in my m68k-build-all-that-builds kernel, I decided to jump into this.

Apparently RPC_DEBUG is set if CONFIG_SYSCTL is defined (<linux/sunrpc/debug.h>), so it builds or not depending on CONFIG_SYSCTL.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]

In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

> Not sure if anyone has submitted this already, but as the > subject implies, net/sunrpc/clnt.c does not compile in either > stock test7 or in current BK:

Only if you do not also set CONFIG_SYSCTL.

     >   CC net/sunrpc/clnt.o net/sunrpc/clnt.c: In function
     >   `call_verify': net/sunrpc/clnt.c:965: structure has no member
     >   named `tk_pid' net/sunrpc/clnt.c:970: structure has no member
     >   named `tk_pid' net/sunrpc/clnt.c:976: structure has no member
     >   named `tk_pid' make[1]: *** [net/sunrpc/clnt.o] Error 1 make:
     >   *** [net/sunrpc/clnt.o] Error 2

> This is due to the fact that tk_pid is protected by > RPC_DEBUG. Wrapping through dprintk() fixes this.

No... You are suppressing legitimate warning messages that inform the user of a client/server mismatch!

Better then to remove the tk_pid from the warning messages...

Cheers
Trond

Is there any reason why tk_pid needs to be under RPC_DEBUG in the first place? If these are legitimate warning messages, presumably it would be nice to know the offending pid as well.

> Is there any reason why tk_pid needs to be under RPC_DEBUG in > the first place? If these are legitimate warning messages, > presumably it would be nice to know the offending pid as well.

It's not a true process pid, but more of a tag on each struct rpc_task. It turns out to be more helpful when you are tracing the (d|)printk() debugging info, since a process may have several rpc_task in flight at any point in time.

Cheers,
Trond

Sounds reasonable. Does this look ok?

@@ -961,19 +961,19 @@
 	case RPC_SUCCESS:
 		return p;
 	case RPC_PROG_UNAVAIL:
-		printk(KERN_WARNING "RPC: %4d call_verify: program %u is unsupported by server %s\n",
-				task->tk_pid, (unsigned int)task->tk_client->cl_prog,
+		printk(KERN_WARNING "RPC: call_verify: program %u is unsupported by server %s\n",
+				(unsigned int)task->tk_client->cl_prog,
 				task->tk_client->cl_server);
 		goto out_eio;
 	case RPC_PROG_MISMATCH:
-		printk(KERN_WARNING "RPC: %4d call_verify: program %u, version %u unsupported by server %s\n",
-				task->tk_pid, (unsigned int)task->tk_client->cl_prog,
+		printk(KERN_WARNING "RPC: call_verify: program %u, version %u unsupported by server %s\n",
+				(unsigned int)task->tk_client->cl_prog,
 				(unsigned int)task->tk_client->cl_vers,
 				task->tk_client->cl_server);
 		goto out_eio;
 	case RPC_PROC_UNAVAIL:
-		printk(KERN_WARNING "RPC: %4d call_verify: proc %p unsupported by program %u, version %u on server %s\n",
-				task->tk_pid, task->tk_msg.rpc_proc,
+		printk(KERN_WARNING "RPC: call_verify: proc %p unsupported by program %u, version %u on server %s\n",
+				task->tk_msg.rpc_proc,
 				task->tk_client->cl_prog,
 				task->tk_client->cl_vers,
 				task->tk_client->cl_server);

> On Thu, Oct 09, 2003 at 12:50:31PM -0400, Trond Myklebust > wrote:
>> It's not a true process pid, but more of a tag on each struct >> rpc_task. It turns out to be more helpful when you are tracing >> the (d|)printk() debugging info, since a process may have >> several rpc_task in flight at any point in time.
>>
> Sounds reasonable. Does this look ok?

Looks fine to me...

Cheers,
Trond