From: Olga Kornievskaia <aglo@citi.umich.edu>
To: Benny Halevy <bhalevy@panasas.com>
Cc: "J. Bruce Fields" <bfields@fieldses.org>,
linux-nfs@vger.kernel.org, pnfs mailing list <pnfs@linux-nfs.org>,
Fred Isaman <iisaman@citi.umich.edu>
Subject: Re: [PATCH] nfsd: use nfs client rpc callback program
Date: Fri, 19 Sep 2008 15:51:04 -0400 [thread overview]
Message-ID: <48D402A8.7020006@citi.umich.edu> (raw)
In-Reply-To: <48D193EE.2020805@panasas.com>
Benny Halevy wrote:
> On Sep. 17, 2008, 18:10 -0500, "J. Bruce Fields" <bfields@fieldses.org> wrote:
>
>> On Wed, Sep 17, 2008 at 02:43:44PM -0500, Benny Halevy wrote:
>>
>>> From: Benny Halevy <bhalevy@panasas.com>
>>>
>>> since commit ff7d9756b501744540be65e172d27ee321d86103
>>> "nfsd: use static memory for callback program and stats"
>>> do_probe_callback uses a static callback program
>>> (NFS4_CALLBACK) rather than the one set in clp->cl_callback.cb_prog
>>> as passed in by the client in setclientid (4.0)
>>> or create_session (4.1).
>>>
>> Ugh, yes, sorry about that. (I wonder why pynfs testing didn't catch
>> this? Oh, I guess it's because NFS4_CALLBACK is the program number our
>> client always gives us.)
>>
>
> Well, Fred (thanks!) added a test today which uses a non-default
> callback program and he sees a corresponding callback coming back.
>
> (Note that this test is not absolutely generic as the server is
> not required to probe the callback immediately, or at all, after
> setclientid or create_session.)
>
>
>>> @@ -371,6 +356,8 @@ static int do_probe_callback(void *data)
>>> .to_maxval = (NFSD_LEASE_TIME/2) * HZ,
>>> .to_exponential = 1,
>>> };
>>> + static struct rpc_stat cb_stats;
>>> + struct rpc_program cb_program;
>>> struct rpc_create_args args = {
>>> .protocol = IPPROTO_TCP,
>>> .address = (struct sockaddr *)&addr,
>>> @@ -394,6 +381,20 @@ static int do_probe_callback(void *data)
>>> addr.sin_port = htons(cb->cb_port);
>>> addr.sin_addr.s_addr = htonl(cb->cb_addr);
>>>
>>> + /* Initialize rpc_program */
>>> + memset(&cb_program, 0, sizeof(cb_program));
>>> + cb_program.name = "nfs4_cb";
>>> + cb_program.number = clp->cl_callback.cb_prog;
>>> + cb_program.nrvers = ARRAY_SIZE(nfs_cb_version);
>>> + cb_program.version = nfs_cb_version;
>>> + cb_program.stats = &cb_stats;
>>> + memset(&cb_stats, 0, sizeof(cb_stats));
>>> + cb_stats.program = &cb_program;
>>>
>> You don't want a pointer to data on the stack here, do you?
>>
>
> Hmm, you're right...
> I went back and forth whether this should be allocated statically,
> dynamically, or on the stack. I was mislead by the fact we're doing
> a sync rpc call, but indeed this needs to live until the nfs client
> is destroyed. I'm trying to fully understand what Olga saw
> before coming up with a new proposal... maybe putting the cb_program
> back into struct nfs4_callback and just make cb_stats static would
> provide a solution of the problem Olga witnessed and keep everybody
> happy.
>
I'm trying really hard to remember what was the issue of not using the
structure and instead using static memory. From what I remember the
issue was that the memory (clp->cl_callback.cb_prog) was going away.
next prev parent reply other threads:[~2008-09-19 20:23 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-09-17 19:43 [PATCH] nfsd: use nfs client rpc callback program Benny Halevy
2008-09-17 23:10 ` J. Bruce Fields
2008-09-17 23:34 ` Benny Halevy
2008-09-18 0:10 ` [pnfs] " Benny Halevy
2008-09-18 19:24 ` Benny Halevy
2008-09-18 19:43 ` Peter Staubach
2008-09-18 20:05 ` Benny Halevy
2008-09-18 21:36 ` Benny Halevy
2008-09-24 16:35 ` J. Bruce Fields
2008-09-24 16:59 ` Trond Myklebust
2008-09-24 17:21 ` J. Bruce Fields
2008-09-24 17:26 ` Trond Myklebust
2008-09-24 17:42 ` J. Bruce Fields
2008-09-24 18:42 ` Trond Myklebust
2008-09-24 18:49 ` J. Bruce Fields
2008-09-25 19:30 ` Benny Halevy
2008-09-25 20:00 ` J. Bruce Fields
2008-09-25 20:27 ` Trond Myklebust
2008-09-25 20:41 ` J. Bruce Fields
2008-09-26 11:52 ` Benny Halevy
2008-09-27 3:34 ` J. Bruce Fields
2008-09-28 6:21 ` [PATCH v4] " Benny Halevy
2008-09-29 19:21 ` J. Bruce Fields
2008-09-25 20:08 ` [pnfs] [PATCH] " Trond Myklebust
2008-09-25 20:38 ` J. Bruce Fields
2008-09-19 19:51 ` Olga Kornievskaia [this message]
2008-09-19 21:15 ` Benny Halevy
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=48D402A8.7020006@citi.umich.edu \
--to=aglo@citi.umich.edu \
--cc=bfields@fieldses.org \
--cc=bhalevy@panasas.com \
--cc=iisaman@citi.umich.edu \
--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 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.