Linux NFS development
 help / color / mirror / Atom feed
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.


  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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox