On Mon, Jan 28, 2008 at 04:14:47PM -0500, Chuck Lever wrote:
> Hi Bruce-
>
> On Jan 28, 2008, at 1:48 PM, J. Bruce Fields wrote:
>> On Mon, Jan 28, 2008 at 12:35:48PM -0500, Chuck Lever wrote:
>>> On Jan 25, 2008, at 6:15 PM, J. Bruce Fields wrote:
>>>> Our callback code doesn't actually handle concurrent attempts to
>>>> probe
>>>> the callback channel. Some rethinking of the locking may be
>>>> required.
>>>> However, we can also just move the callback probing to this case.
>>>> Since
>>>> this is the only time a client is "confirmed" (and since that can
>>>> only
>>>> happen once in the lifetime of a client), this ensures we only probe
>>>> once.
>>>
>>> Applying 001/100 without applying 002/100 will probably break
>>> bisectability.
>>
>> You lost me here. Why? I'm probably just missing something obvious.
>
>
> Because, even though the kernel compiles with just 001, it doesn't work
> properly.
Why not? Treat me like a tired person here ('cause that would be
accurate) and break it down really carefully....
> In fact, it may even Oops, if I read 002 right, since no RPC
> client is available to do the probe?
An rpc client is created in nfsd4_probe_callback():
/* Create RPC client */
cb->cb_client = rpc_create(&args);
if (IS_ERR(cb->cb_client)) {
dprintk("NFSD: couldn't create callback client\n");
goto out_err;
}
/* the task holds a reference to the nfs4_client struct */
atomic_inc(&clp->cl_count);
t = kthread_run(do_probe_callback, clp, "nfs4_cb_probe");
All #2 does is move that rpc_create() into the do_probe_callback() called in
the new thread.
--b.
-
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
