Re: [PATCH v2 40/47] nfsd41: cb_sequence callback

["J. Bruce Fields" <bfields@fieldses.org>]

On Thu, Apr 02, 2009 at 10:20:08PM +0300, Benny Halevy wrote:
> On Apr. 02, 2009, 21:51 +0300, "J. Bruce Fields" <bfields@fieldses.org> wrote:
> > On Thu, Apr 02, 2009 at 11:47:24AM +0300, Benny Halevy wrote:
> >> On Apr. 01, 2009, 7:39 +0300, "J. Bruce Fields" <bfields@fieldses.org> wrote:
> >>>> @@ -503,6 +589,38 @@ nfsd4_probe_callback(struct nfs4_client *clp)
> >>>>  	return;
> >>>>  }
> >>>>  
> >>>> +#if defined(CONFIG_NFSD_V4_1)
> >>>> +/*
> >>>> + * FIXME: cb_sequence should support referring call lists, cachethis, and
> >>>> + * multiple slots
> >>>> + */
> >>>> +static int
> >>>> +nfs41_cb_sequence_setup(struct nfs4_client *clp, struct nfsd4_cb_sequence *args)
> >>>> +{
> >>>> +	u32 *ptr = (u32 *)clp->cl_sessionid.data;
> >>>> +
> >>>> +	dprintk("%s: %u:%u:%u:%u\n", __func__,
> >>>> +		ptr[0], ptr[1], ptr[2], ptr[3]);
> >>>> +
> >>>> +	mutex_lock(&clp->cl_cb_mutex);
> >>> We shouldn't be holding a mutex across a callback.  Why is this needed?
> >> Just a simple way to limit concurrency to 1 and not deal with
> >> multiple slots on the callback path.
> > 
> > OK.  We should work out some sort of asynchronous equivalent.
> 
> OK.
> 
> > How is the client side currently waiting on slots?
> 
> Currently it has a single slot and a single
> (NFS41_BC_MIN_CALLBACKS) preallocated rpc_rqst.
> If it gets more calls than that, concurrently, it will
> drop its end of the line using 
> set_bit(XPRT_CLOSE_WAIT, &xprt->state)
> 
> (Ricardo, please keep me honest :)

I was wondering about the rpc client as used on the nfs client, not the
nfs client/callback server.

--b.