On Apr. 02, 2009, 22:27 +0300, "J. Bruce Fields" <bfields@xxxxxxxxxxxx> wrote:
> 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
you mean rpc client as used on the nfs server? :)
> 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
