[illumos-Developer] webrev for 1107

[Dan Kruchinin]

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.

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