* Re: new 2.6.22-git5 warnings
2007-07-14 15:37 new 2.6.22-git5 warnings Randy Dunlap
@ 2007-07-14 16:53 ` Trond Myklebust
0 siblings, 0 replies; 2+ messages in thread
From: Trond Myklebust @ 2007-07-14 16:53 UTC (permalink / raw)
To: Randy Dunlap; +Cc: lkml, bfields
[-- Attachment #1: Type: text/plain, Size: 418 bytes --]
On Sat, 2007-07-14 at 08:37 -0700, Randy Dunlap wrote:
>
> net/sunrpc/auth_gss/auth_gss.c:1002: warning: implicit declaration of function 'lock_kernel'
> net/sunrpc/auth_gss/auth_gss.c:1004: warning: implicit declaration of function 'unlock_kernel'
>
>
> allmodconfig or allyesconfig on x86_64.
Yup. Sorry about that. Bruce has proposed a cleanup which should also
fix this problem. See attachment
Cheers
Trond
[-- Attachment #2: Attached message - [PATCH] sunrpc: move bkl locking and xdr proc invocation into a common function --]
[-- Type: message/rfc822, Size: 7073 bytes --]
From: "J. Bruce Fields" <bfields@fieldses.org>
To: Trond Myklebust <trond.myklebust@fys.uio.no>
Cc: nfsv4@linux-nfs.org
Subject: [PATCH] sunrpc: move bkl locking and xdr proc invocation into a common function
Date: Wed, 11 Jul 2007 18:39:02 -0400
Message-ID: <20070711223902.GM4138@fieldses.org>
From: J. Bruce Fields <bfields@citi.umich.edu>
Since every invocation of xdr encode or decode functions takes the BKL now,
there's a lot of redundant lock_kernel/unlock_kernel pairs that we can pull out
into a common function.
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
---
include/linux/sunrpc/xdr.h | 16 ++++++++++++++++
net/sunrpc/auth.c | 12 ++----------
net/sunrpc/auth_gss/auth_gss.c | 20 +++++---------------
3 files changed, 23 insertions(+), 25 deletions(-)
> It's fine to keep it as a separate patch, but you're going to have to do
> something about the name: do_xdrproc() breaks with the standard sunrpc
> namespace conventions. How about naming it rpc_call_xdrproc().
Sounds fine. Here's take two, with the new name and an additional
comment.
--b.
diff --git a/include/linux/sunrpc/xdr.h b/include/linux/sunrpc/xdr.h
index 9e340fa..c6b53d1 100644
--- a/include/linux/sunrpc/xdr.h
+++ b/include/linux/sunrpc/xdr.h
@@ -12,6 +12,7 @@
#include <linux/uio.h>
#include <asm/byteorder.h>
#include <linux/scatterlist.h>
+#include <linux/smp_lock.h>
/*
* Buffer adjustment
@@ -36,6 +37,21 @@ struct xdr_netobj {
typedef int (*kxdrproc_t)(void *rqstp, __be32 *data, void *obj);
/*
+ * We're still requiring the BKL in the xdr code until it's been
+ * more carefully audited, at which point this wrapper will become
+ * unnecessary.
+ */
+static inline int rpc_call_xdrproc(kxdrproc_t xdrproc, void *rqstp, __be32 *data, void *obj)
+{
+ int ret;
+
+ lock_kernel();
+ ret = xdrproc(rqstp, data, obj);
+ unlock_kernel();
+ return ret;
+}
+
+/*
* Basic structure for transmission/reception of a client XDR message.
* Features a header (for a linear buffer containing RPC headers
* and the data payload for short messages), and then an array of
diff --git a/net/sunrpc/auth.c b/net/sunrpc/auth.c
index e04da66..cd31cbd 100644
--- a/net/sunrpc/auth.c
+++ b/net/sunrpc/auth.c
@@ -359,17 +359,13 @@ rpcauth_wrap_req(struct rpc_task *task, kxdrproc_t encode, void *rqstp,
__be32 *data, void *obj)
{
struct rpc_cred *cred = task->tk_msg.rpc_cred;
- int ret;
dprintk("RPC: %5u using %s cred %p to wrap rpc data\n",
task->tk_pid, cred->cr_ops->cr_name, cred);
if (cred->cr_ops->crwrap_req)
return cred->cr_ops->crwrap_req(task, encode, rqstp, data, obj);
/* By default, we encode the arguments normally. */
- lock_kernel();
- ret = encode(rqstp, data, obj);
- unlock_kernel();
- return ret;
+ return rpc_call_xdrproc(encode, rqstp, data, obj);
}
int
@@ -377,7 +373,6 @@ rpcauth_unwrap_resp(struct rpc_task *task, kxdrproc_t decode, void *rqstp,
__be32 *data, void *obj)
{
struct rpc_cred *cred = task->tk_msg.rpc_cred;
- int ret;
dprintk("RPC: %5u using %s cred %p to unwrap rpc data\n",
task->tk_pid, cred->cr_ops->cr_name, cred);
@@ -385,10 +380,7 @@ rpcauth_unwrap_resp(struct rpc_task *task, kxdrproc_t decode, void *rqstp,
return cred->cr_ops->crunwrap_resp(task, decode, rqstp,
data, obj);
/* By default, we decode the arguments normally. */
- lock_kernel();
- ret = decode(rqstp, data, obj);
- unlock_kernel();
- return ret;
+ return rpc_call_xdrproc(decode, rqstp, data, obj);
}
int
diff --git a/net/sunrpc/auth_gss/auth_gss.c b/net/sunrpc/auth_gss/auth_gss.c
index a001973..73fd24c 100644
--- a/net/sunrpc/auth_gss/auth_gss.c
+++ b/net/sunrpc/auth_gss/auth_gss.c
@@ -917,9 +917,7 @@ gss_wrap_req_integ(struct rpc_cred *cred, struct gss_cl_ctx *ctx,
offset = (u8 *)p - (u8 *)snd_buf->head[0].iov_base;
*p++ = htonl(rqstp->rq_seqno);
- lock_kernel();
- status = encode(rqstp, p, obj);
- unlock_kernel();
+ status = rpc_call_xdrproc(encode, rqstp, p, obj);
if (status)
return status;
@@ -1013,9 +1011,7 @@ gss_wrap_req_priv(struct rpc_cred *cred, struct gss_cl_ctx *ctx,
offset = (u8 *)p - (u8 *)snd_buf->head[0].iov_base;
*p++ = htonl(rqstp->rq_seqno);
- lock_kernel();
- status = encode(rqstp, p, obj);
- unlock_kernel();
+ status = rpc_call_xdrproc(encode, rqstp, p, obj);
if (status)
return status;
@@ -1074,16 +1070,12 @@ gss_wrap_req(struct rpc_task *task,
/* The spec seems a little ambiguous here, but I think that not
* wrapping context destruction requests makes the most sense.
*/
- lock_kernel();
- status = encode(rqstp, p, obj);
- unlock_kernel();
+ status = rpc_call_xdrproc(encode, rqstp, p, obj);
goto out;
}
switch (gss_cred->gc_service) {
case RPC_GSS_SVC_NONE:
- lock_kernel();
- status = encode(rqstp, p, obj);
- unlock_kernel();
+ status = rpc_call_xdrproc(encode, rqstp, p, obj);
break;
case RPC_GSS_SVC_INTEGRITY:
status = gss_wrap_req_integ(cred, ctx, encode,
@@ -1199,9 +1191,7 @@ gss_unwrap_resp(struct rpc_task *task,
task->tk_auth->au_rslack = task->tk_auth->au_verfsize + (p - savedp)
+ (savedlen - head->iov_len);
out_decode:
- lock_kernel();
- status = decode(rqstp, p, obj);
- unlock_kernel();
+ status = rpc_call_xdrproc(decode, rqstp, p, obj);
out:
gss_put_ctx(ctx);
dprintk("RPC: %5u gss_unwrap_resp returning %d\n", task->tk_pid,
--
1.5.3.rc0.63.gc956
^ permalink raw reply [flat|nested] 2+ messages in thread