On Thu, Apr 02, 2009 at 10:20:08PM +0300, Benny Halevy wrote:
> On Apr. 02, 2009, 21:51 +0300, "J. Bruce Fields" <bfields@xxxxxxxxxxxx> 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@xxxxxxxxxxxx> 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.
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
