From: "Labiaga, Ricardo" <ricardo.labiaga@netapp.com>
To: Benny Halevy <bhalevy@panasas.com>
Cc: <bfields@fieldses.org>, <pnfs@linux-nfs.org>,
<linux-nfs@vger.kernel.org>, Andy Adamson <andros@netapp.com>
Subject: Re: [RFC 10/11] nfsd41: Backchannel: Implement cb_recall over NFSv4.1
Date: Wed, 20 May 2009 11:17:04 -0700 [thread overview]
Message-ID: <C6399730.6262%ricardo.labiaga@netapp.com> (raw)
In-Reply-To: <4A13B55A.3030405@panasas.com>
On 5/20/09 12:46 AM, "Benny Halevy" <bhalevy@panasas.com> wrote:
> On May. 20, 2009, 6:00 +0300, Ricardo Labiaga <Ricardo.Labiaga@netapp.com>
> wrote:
>> Signed-off-by: Ricardo Labiaga <Ricardo.Labiaga@netapp.com>
>> [nfsd41: cb_recall callback]
>> [Share v4.0 and v4.1 back channel xdr]
>> Signed-off-by: Andy Adamson <andros@netapp.com>
>> Signed-off-by: Ricardo Labiaga <ricardo.labiaga@netapp.com>
>> Signed-off-by: Benny Halevy <bhalevy@panasas.com>
>> [Share v4.0 and v4.1 back channel xdr]
>> Signed-off-by: Andy Adamson <andros@netapp.com>
>> Signed-off-by: Benny Halevy <bhalevy@panasas.com>
>> [nfsd41: use nfsd4_cb_sequence for callback minorversion]
>> [nfsd41: conditionally decode_sequence in nfs4_xdr_dec_cb_recall]
>> Signed-off-by: Benny Halevy <bhalevy@panasas.com>
>> [nfsd41: Backchannel: Add sequence arguments to callback RPC arguments]
>> Signed-off-by: Ricardo Labiaga <Ricardo.Labiaga@netapp.com>
>> Signed-off-by: Benny Halevy <bhalevy@panasas.com>
>> ---
>> fs/nfsd/nfs4callback.c | 40 ++++++++++++++++++++++++++++++++++++----
>> 1 files changed, 36 insertions(+), 4 deletions(-)
>>
>> diff --git a/fs/nfsd/nfs4callback.c b/fs/nfsd/nfs4callback.c
>> index 521d5f5..b25dcc2 100644
>> --- a/fs/nfsd/nfs4callback.c
>> +++ b/fs/nfsd/nfs4callback.c
>> @@ -292,15 +292,19 @@ nfs4_xdr_enc_cb_null(struct rpc_rqst *req, __be32 *p)
>> }
>>
>> static int
>> -nfs4_xdr_enc_cb_recall(struct rpc_rqst *req, __be32 *p, struct
>> nfs4_delegation *args)
>> +nfs4_xdr_enc_cb_recall(struct rpc_rqst *req, __be32 *p,
>> + struct nfs4_rpc_args *rpc_args)
>> {
>> struct xdr_stream xdr;
>> + struct nfs4_delegation *args = rpc_args->args_op;
>> struct nfs4_cb_compound_hdr hdr = {
>> .ident = args->dl_ident,
>> + .minorversion = rpc_args->args_seq.cbs_minorversion,
>> };
>>
>> xdr_init_encode(&xdr, &req->rq_snd_buf, p);
>> encode_cb_compound_hdr(&xdr, &hdr);
>> + encode_cb_sequence(&xdr, &rpc_args->args_seq, &hdr);
>> encode_cb_recall(&xdr, args, &hdr);
>> encode_cb_nops(&hdr);
>> return 0;
>> @@ -400,7 +404,8 @@ nfs4_xdr_dec_cb_null(struct rpc_rqst *req, __be32 *p)
>> }
>>
>> static int
>> -nfs4_xdr_dec_cb_recall(struct rpc_rqst *rqstp, __be32 *p)
>> +nfs4_xdr_dec_cb_recall(struct rpc_rqst *rqstp, __be32 *p,
>> + struct nfs4_rpc_res *rpc_res)
>> {
>> struct xdr_stream xdr;
>> struct nfs4_cb_compound_hdr hdr;
>> @@ -410,6 +415,11 @@ nfs4_xdr_dec_cb_recall(struct rpc_rqst *rqstp, __be32
>> *p)
>> status = decode_cb_compound_hdr(&xdr, &hdr);
>> if (status)
>> goto out;
>> + if (rpc_res && rpc_res->res_seq) {
>
> With this version rpc_res != NULL is guaranteed, isn't it?
> Also, embedding res_seq in nfs4_rpc_res will obviate this condition further.
True, rpc_res will always be non-NULL but rpc_res->res_seq is still NULL if
this is a v4.0 callback.
>
>> + status = decode_cb_sequence(&xdr, rpc_res->res_seq, rqstp);
>> + if (status)
>> + goto out;
>> + }
>> status = decode_cb_op_hdr(&xdr, OP_CB_RECALL);
>> out:
>> return status;
>> @@ -687,6 +697,8 @@ static void nfsd4_cb_recall_done(struct rpc_task *task,
>> void *calldata)
>> struct nfs4_delegation *dp = calldata;
>> struct nfs4_client *clp = dp->dl_client;
>>
>> + nfsd4_cb_done(task, calldata);
>> +
>> switch (task->tk_status) {
>> case -EIO:
>> /* Network partition? */
>> @@ -699,16 +711,20 @@ static void nfsd4_cb_recall_done(struct rpc_task *task,
>> void *calldata)
>> break;
>> default:
>> /* success, or error we can't handle */
>> - return;
>> + goto done;
>> }
>> if (dp->dl_retries--) {
>> rpc_delay(task, 2*HZ);
>> task->tk_status = 0;
>> rpc_restart_call(task);
>> + return;
>> } else {
>> atomic_set(&clp->cl_cb_conn.cb_set, 0);
>> warn_no_callback_path(clp, task->tk_status);
>> }
>> +done:
>> + kfree(task->tk_msg.rpc_argp);
>> + kfree(task->tk_msg.rpc_resp);
>> }
>>
>> static void nfsd4_cb_recall_release(void *calldata)
>> @@ -734,16 +750,32 @@ nfsd4_cb_recall(struct nfs4_delegation *dp)
>> {
>> struct nfs4_client *clp = dp->dl_client;
>> struct rpc_clnt *clnt = clp->cl_cb_conn.cb_client;
>> + struct nfs4_rpc_args *args;
>> + struct nfs4_rpc_res *res;
>> struct rpc_message msg = {
>> .rpc_proc = &nfs4_cb_procedures[NFSPROC4_CLNT_CB_RECALL],
>> - .rpc_argp = dp,
>> .rpc_cred = clp->cl_cb_conn.cb_cred
>> };
>> int status;
>>
>> + args = kzalloc(sizeof(*args), GFP_KERNEL);
>> + if (!args) {
>> + status = -ENOMEM;
>> + goto out;
>> + }
>> + res = kzalloc(sizeof(*res), GFP_KERNEL);
>> + if (!res) {
>> + kfree(args);
>> + status = -ENOMEM;
>> + goto out;
>> + }
>
> Hmm, why not allocate the two in one piece and possibly having a kmem_cache
> for them?
They're two different types of structures. You mean encapsulate them in a
super structure and then have the pointers to respective members? I'm not
following.
- ricardo
> Benny
>
>> + args->args_op = dp;
>> + msg.rpc_argp = args;
>> + msg.rpc_resp = res;
>> dp->dl_retries = 1;
>> status = rpc_call_async(clnt, &msg, RPC_TASK_SOFT,
>> &nfsd4_cb_recall_ops, dp);
>> +out:
>> if (status) {
>> put_nfs4_client(clp);
>> nfs4_put_delegation(dp);
next prev parent reply other threads:[~2009-05-20 18:17 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-05-20 2:07 [RFC 0/10] nfsd41 server backchannel for 2.6.31 Labiaga, Ricardo
[not found] ` <273FE88A07F5D445824060902F70034405CEB64D-hX7t0kiaRRpT+ZUat5FNkAK/GNPrWCqfQQ4Iyu8u01E@public.gmane.org>
2009-05-20 3:00 ` [RFC 01/11] nfsd: cleanup nfs4.0 callback encode routines Ricardo Labiaga
2009-05-20 3:00 ` [RFC 02/11] nfsd: minorversion support for the back channel Ricardo Labiaga
2009-05-20 3:00 ` [RFC 03/11] nfsd41: sunrpc: svc_tcp_recv_record() Ricardo Labiaga
2009-05-20 3:00 ` [RFC 04/11] nfsd41: sunrpc: Added rpc server-side backchannel handling Ricardo Labiaga
2009-05-20 3:00 ` [RFC 05/11] nfsd41: callback infrastructure Ricardo Labiaga
2009-05-20 3:00 ` [RFC 06/11] nfsd41: Backchannel: Add sequence arguments to callback RPC arguments Ricardo Labiaga
2009-05-20 3:00 ` [RFC 07/11] nfsd41: Backchannel: Server backchannel RPC wait queue Ricardo Labiaga
2009-05-20 3:00 ` [RFC 08/11] nfsd41: Backchannel: Setup sequence information Ricardo Labiaga
2009-05-20 3:00 ` [RFC 09/11] nfsd41: cb_sequence callback Ricardo Labiaga
2009-05-20 3:00 ` [RFC 10/11] nfsd41: Backchannel: Implement cb_recall over NFSv4.1 Ricardo Labiaga
2009-05-20 3:00 ` [RFC 11/11] nfsd41: Refactor create_client() Ricardo Labiaga
2009-05-20 8:18 ` Benny Halevy
2009-05-20 18:27 ` Labiaga, Ricardo
2009-05-20 7:46 ` [RFC 10/11] nfsd41: Backchannel: Implement cb_recall over NFSv4.1 Benny Halevy
2009-05-20 18:17 ` Labiaga, Ricardo [this message]
2009-05-21 5:59 ` Benny Halevy
2009-05-21 6:54 ` Labiaga, Ricardo
2009-05-20 7:32 ` [RFC 06/11] nfsd41: Backchannel: Add sequence arguments to callback RPC arguments Benny Halevy
2009-05-20 18:05 ` Labiaga, Ricardo
2009-05-20 8:34 ` [RFC 04/11] nfsd41: sunrpc: Added rpc server-side backchannel handling Benny Halevy
2009-05-20 18:40 ` Labiaga, Ricardo
2009-05-20 3:04 ` [pnfs] [RFC 0/10] nfsd41 server backchannel for 2.6.31 Labiaga, Ricardo
-- strict thread matches above, loose matches on Subject: below --
2009-06-06 2:48 [RFC 0/10] nfsd41 server backchannel for 2.6.31 (try 3) Labiaga, Ricardo
2009-06-06 2:49 ` [RFC 01/11] nfsd41: Backchannel: cleanup nfs4.0 callback encode routines Ricardo Labiaga
2009-06-06 2:49 ` [RFC 02/11] nfsd41: Backchannel: minorversion support for the back channel Ricardo Labiaga
2009-06-06 2:49 ` [RFC 03/11] nfsd41: sunrpc: svc_tcp_recv_record() Ricardo Labiaga
2009-06-06 2:49 ` [RFC 04/11] nfsd41: sunrpc: Added rpc server-side backchannel handling Ricardo Labiaga
2009-06-06 2:50 ` [RFC 05/11] nfsd41: Backchannel: callback infrastructure Ricardo Labiaga
2009-06-06 2:50 ` [RFC 06/11] nfsd41: Backchannel: Add sequence arguments to callback RPC arguments Ricardo Labiaga
2009-06-06 2:50 ` [RFC 07/11] nfsd41: Backchannel: Server backchannel RPC wait queue Ricardo Labiaga
2009-06-06 2:50 ` [RFC 08/11] nfsd41: Backchannel: Setup sequence information Ricardo Labiaga
2009-06-06 2:50 ` [RFC 09/11] nfsd41: Backchannel: cb_sequence callback Ricardo Labiaga
2009-06-06 2:50 ` [RFC 10/11] nfsd41: Backchannel: Implement cb_recall over NFSv4.1 Ricardo Labiaga
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=C6399730.6262%ricardo.labiaga@netapp.com \
--to=ricardo.labiaga@netapp.com \
--cc=andros@netapp.com \
--cc=bfields@fieldses.org \
--cc=bhalevy@panasas.com \
--cc=linux-nfs@vger.kernel.org \
--cc=pnfs@linux-nfs.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox