[illumos-Developer] webrev for 1107

[Dan Kruchinin]

On Tue, Jun 14, 2011 at 3:57 AM, Dan Kruchinin <dkruchinin at acm.org> wrote:
> Brief looking at current KLM design showed that it won't work.
> We have a chicken and egg problem (please, correct me if I'm wrong):
>
> Before start, KLM waits lockd to call nlmsvc with loopback (ticotsord
> device) netconfig. (for start
> it doesn't interested in file descriptor associated with another peer,
> it just needs to get valid netid and netconfig
> to make initial report to statd).
>
> if do_one() function ignores all COTS (because they are initialized
> when new client appears), it will ignore ticotsord.
> If it will ignore ticotsord, KLM will never start, because statd won't
> try to establish connection via loopback
> until KLM report that it ready to work.
>
> We can fix that problem by three ways:
> 1) The easiest one:
> replace a check  nc->nc_semantics == NC_TPI_CLTS
> with
> nc->nc_semantics == NC_TPI_CLTS || !strcmp(nc->nc_protofmly, NC_LOOPBACK)
>
> 2) Before start, KLM can explicitly prepare information about netid
> and knetconfig that can
> be used for RPC calls via loopback.
> lm_svc_args can be extended by one new member - for example "int start".
> After lockd does all job  server confwithiguration using do_one(), it explicitly
> calls nlmsvc with empty proto, family and fd, but with start = 1.
> KLM detects that args->start == 1 and tries to execute initialization code and
> connect to statd.

Forgot (3):
3) Dedicate another nfsssys opcode for KLM start command.

>
> P/S:
> I think that (1) is better solution.
>
> On Tue, Jun 14, 2011 at 1:21 AM, Gordon Ross <gordon.w.ross at gmail.com> wrote:
>> On Mon, Jun 13, 2011 at 4:45 PM, Vitaliy Gusev
>> <gusev.vitaliy at nexenta.com> wrote:
>>>>>
>>>>> No, do_one doesn't call do_poll_cots_action. I as mentioned early,
>>>>> call stack is:
>>>>>
>>>>>   poll_for_action
>>>>>        do_poll_cots_action
>>>>>             cots_listen_event
>>>>
>>>> Heh, your're right, I confused poll_for_actions with add_to_poll_list,
>>>> which is called by do_one.
>>>> But your point point opens several questions. First of all I need to
>>>> explain why we need OK_TPI_TYPE
>>>> instead of checking of nc_semantics on  NC_TPI_CLTS only.
>>>
>>>
>>> I think it creates kernel thread on each connect for COTS - so we can do it
>>> only on connect, whereas for udp it can be started at once.
>>>
>>>
>>>>
>>>> Both nfsd and lockd calls do_one function and pass svc callback to it.
>>>> In case of lockd svc callback
>>>> is nlmsvc function which calls LM_SVC nfs syscall that opens in its
>>>> turn makes kernel to register
>>>> kRPC server handles for given protocols and devices. By some reason
>>>
>>> ...
>>>
>>>> In case of nfsd do_one function calls nfssvc callback for CLTS only.
>>>> nfssvc calls NFS_SVC nfssys
>>>> that in its turn creates kRPC server handle. According to the code,
>>>> nfs_tbind.c will create only CLTS
>>>> kRPC server handles for nfsd. Is it right?
>>>
>>>
>>>
>>> 1. For udp it will be called at once from do_one()
>>>
>>> 2. For tcp it delays until incoming connection arrives. For nfsd see to
>>>
>>>
>>> *** src/cmd/fs.d/nfs/nfsd/nfsd.c:
>>>         int (*Mysvc)(int , struct netbuf, struct netconfig *) = nfssvc;
>>>
>>> *** src/cmd/fs.d/nfs/lib/nfs_tbind.c:
>>> cots_listen_event[1425]        ret = (*Mysvc)(new_fd, addrmask, nconf);
>>
>> Right, so for connection-oriented transports:
>> nfs_tbind.c: do_one() calls
>>   add_to_poll_list() with the listening endpoint.
>>
>> When that listening endpoint gets a poll event,
>> (typically a connection indication) it will call:
>>  do_poll_cots_action(),
>>    cots_listen_event(),
>> which will accept the connection and then
>> start RPC services on it (Mysvc, etc).
>>
>> So the original check is correct:
>>  nc->nc_semantics == NC_TPI_CLTS
>> (A comment would help :)
>>
>> Gordon
>>
>
>
>
> --
> W.B.R.
> Dan Kruchinin
>



-- 
W.B.R.
Dan Kruchinin