From: "J. Bruce Fields" <bfields@fieldses.org>
To: Benny Halevy <bhalevy@panasas.com>
Cc: Ricardo Labiaga <Ricardo.Labiaga@netapp.com>,
pnfs@linux-nfs.org, linux-nfs@vger.kernel.org,
Rahul Iyer <iyer@netapp.com>, Mike Sager <sager@netapp.com>,
Marc Eshel <eshel@almaden.ibm.com>,
Andy Adamson <andros@netapp.com>
Subject: Re: [RFC 03/10] nfsd41: sunrpc: Added rpc server-side backchannel handling
Date: Sun, 3 May 2009 16:36:45 -0400 [thread overview]
Message-ID: <20090503203645.GA22306@fieldses.org> (raw)
In-Reply-To: <1241132750-32462-1-git-send-email-bhalevy@panasas.com>
On Fri, May 01, 2009 at 02:05:50AM +0300, Benny Halevy wrote:
> diff --git a/net/sunrpc/svcsock.c b/net/sunrpc/svcsock.c
> index 4e6d406..619764e 100644
> --- a/net/sunrpc/svcsock.c
> +++ b/net/sunrpc/svcsock.c
> @@ -49,6 +49,7 @@
> #include <linux/sunrpc/msg_prot.h>
> #include <linux/sunrpc/svcsock.h>
> #include <linux/sunrpc/stats.h>
> +#include <linux/sunrpc/xprt.h>
>
> #define RPCDBG_FACILITY RPCDBG_SVCXPRT
>
> @@ -825,6 +826,7 @@ static int svc_tcp_recvfrom(struct svc_rqst *rqstp)
> int len;
> struct kvec *vec;
> int pnum, vlen;
> + struct rpc_rqst *req = NULL;
>
> dprintk("svc: tcp_recv %p data %d conn %d close %d\n",
> svsk, test_bit(XPT_DATA, &svsk->sk_xprt.xpt_flags),
> @@ -891,12 +893,65 @@ static int svc_tcp_recvfrom(struct svc_rqst *rqstp)
> len = svsk->sk_reclen;
> set_bit(XPT_DATA, &svsk->sk_xprt.xpt_flags);
>
> + /*
> + * We have enough data for the whole tcp record. Let's try and read the
> + * first 8 bytes to get the xid and the call direction. We can use this
> + * to figure out if this is a call or a reply to a callback. If
> + * sk_reclen is < 8 (xid and calldir), then this is a malformed packet.
> + * In that case, don't bother with the calldir and just read the data.
> + * It will be rejected in svc_process.
> + */
> +
> vec = rqstp->rq_vec;
> vec[0] = rqstp->rq_arg.head[0];
> vlen = PAGE_SIZE;
> +
> + if (len >= 8) {
> + u32 *p;
> + u32 xid;
> + u32 calldir;
Style complaint: "Functions should be short and sweet, and do just one
thing." The code in this "if" clause looks like something that could
easily be encapsulated in a helper function.
> +
> + len = svc_recvfrom(rqstp, vec, 1, 8);
> + if (len < 0)
> + goto error;
> +
> + p = (u32 *)rqstp->rq_arg.head[0].iov_base;
> + xid = *p++;
> + calldir = *p;
> +
> + if (calldir) {
> + /* REPLY */
> + if (svsk->sk_bc_xprt)
> + req = xprt_lookup_rqst(svsk->sk_bc_xprt, xid);
> + if (req) {
> + memcpy(&req->rq_private_buf, &req->rq_rcv_buf,
> + sizeof(struct xdr_buf));
This worries me. Has anyone tested this with krb5p? If not, please do.
> + /* copy the xid and call direction */
> + memcpy(req->rq_private_buf.head[0].iov_base,
> + rqstp->rq_arg.head[0].iov_base, 8);
> + vec[0] = req->rq_private_buf.head[0];
> + } else
> + printk(KERN_NOTICE
> + "%s: Got unrecognized reply: "
> + "calldir 0x%x sk_bc_xprt %p xid %08x\n",
> + __func__, ntohl(calldir),
> + svsk->sk_bc_xprt, xid);
> + }
And another style nit: other things being equal, I'd generally prefer
if (exceptional case)
handle it, goto/return
if (another exceptional case)
handle it, goto/return
...
normal case
...
to
if (normal case) {
...
normal case
...
} else
handle exceptional case
--b.
next prev parent reply other threads:[~2009-05-03 20:36 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-04-30 23:00 [RFC 0/10] nfsd41 server backchannel for 2.6.31 Benny Halevy
2009-04-30 23:05 ` [RFC 01/10] nfsd: cleanup nfs4.0 callback encode routines Benny Halevy
2009-04-30 23:05 ` [RFC 02/10] nfsd: minorversion support for the back channel Benny Halevy
2009-04-30 23:05 ` [RFC 03/10] nfsd41: sunrpc: Added rpc server-side backchannel handling Benny Halevy
2009-05-01 0:05 ` [pnfs] " Trond Myklebust
[not found] ` <1241136328.15476.124.camel-rJ7iovZKK19ZJLDQqaL3InhyD016LWXt@public.gmane.org>
2009-05-01 0:13 ` Labiaga, Ricardo
2009-06-02 0:33 ` Labiaga, Ricardo
[not found] ` <273FE88A07F5D445824060902F70034405FE3129-hX7t0kiaRRpT+ZUat5FNkAK/GNPrWCqfQQ4Iyu8u01E@public.gmane.org>
2009-06-02 0:52 ` J. Bruce Fields
2009-06-02 1:24 ` [pnfs] [RFC 03/10] nfsd41: sunrpc: Added rpc server-sidebackchannel handling Labiaga, Ricardo
2009-06-02 4:51 ` [pnfs] [RFC 03/10] nfsd41: sunrpc: Added rpc server-side backchannel handling Benny Halevy
[not found] ` <273FE88A07F5D445824060902F70034402030375@SACMVEXC1-PRD.hq.netapp.com>
[not found] ` <273FE88A07F5D445824060902F70034402030375-hX7t0kiaRRpT+ZUat5FNkAK/GNPrWCqfQQ4Iyu8u01E@public.gmane.org>
2009-06-03 8:44 ` Benny Halevy
2009-05-03 20:36 ` J. Bruce Fields [this message]
2009-04-30 23:06 ` [RFC 04/10] nfsd41: Remember the auth flavor to use for callbacks Benny Halevy
2009-05-03 20:42 ` J. Bruce Fields
2009-05-05 2:51 ` [RFC 04/10] nfsd41: Remember the auth flavor to use forcallbacks Labiaga, Ricardo
2009-04-30 23:06 ` [RFC 05/10] nfsd41: callback infrastructure Benny Halevy
2009-05-03 20:49 ` J. Bruce Fields
2009-04-30 23:06 ` [RFC 06/10] nfsd41: Backchannel: Add sequence arguments to callback RPC arguments Benny Halevy
2009-04-30 23:06 ` [RFC 07/10] nfsd41: Backchannel: Server backchannel RPC wait queue Benny Halevy
2009-04-30 23:06 ` [RFC 08/10] nfsd41: Backchannel: Setup sequence information Benny Halevy
2009-04-30 23:06 ` [RFC 09/10] nfsd41: cb_sequence callback Benny Halevy
2009-04-30 23:52 ` [pnfs] " Trond Myklebust
[not found] ` <1241135565.15476.111.camel-rJ7iovZKK19ZJLDQqaL3InhyD016LWXt@public.gmane.org>
2009-05-01 8:33 ` Benny Halevy
2009-04-30 23:07 ` [RFC 10/10] nfsd41: cb_recall callback Benny Halevy
2009-04-30 23:12 ` [pnfs] [RFC 0/10] nfsd41 server backchannel for 2.6.31 Benny Halevy
2009-05-03 20:53 ` J. Bruce Fields
2009-05-06 4:11 ` Labiaga, Ricardo
2009-05-06 21:24 ` J. Bruce Fields
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20090503203645.GA22306@fieldses.org \
--to=bfields@fieldses.org \
--cc=Ricardo.Labiaga@netapp.com \
--cc=andros@netapp.com \
--cc=bhalevy@panasas.com \
--cc=eshel@almaden.ibm.com \
--cc=iyer@netapp.com \
--cc=linux-nfs@vger.kernel.org \
--cc=pnfs@linux-nfs.org \
--cc=sager@netapp.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.