Re: Use of delayed request information in nlmsvc_lookup_host

[Chuck Lever <chuck.lever@oracle.com>]

[-- Attachment #1: Type: text/plain, Size: 1816 bytes --]

Trond Myklebust wrote:
> On Wed, 2007-11-14 at 13:23 -0500, Chuck Lever wrote:
>> Hi-
>>
>> Historical question here.
>>
>> nlmsvc_lookup_host() has this:
>>
>> struct nlm_host *
>> nlmsvc_lookup_host(struct svc_rqst *rqstp,
>>                          const char *hostname, unsigned int hostname_len)
>> {
>>          struct sockaddr_in ssin = {0};
>>
>>  >>>     ssin.sin_addr = rqstp->rq_daddr.addr;
>>          return nlm_lookup_host(1, svc_addr_in(rqstp),
>>                                 rqstp->rq_prot, rqstp->rq_vers,
>>                                 hostname, hostname_len, &ssin);
>> }
>>
>> Why is it using rq_daddr to construct the lookup target?
>>
>> The problem here is that rq_daddr isn't a full address.  It doesn't have 
>> address family information.  So nlmsvc_lookup_host() just assumes that 
>> what's stored in rq_daddr is always AF_INET.
> 
> Why can't rq_daddr hold address family information? AFAICS there is
> nothing stopping you from setting that in svc_recvfrom() and in
> svc_udp_get_dest_address().

That's correct.  I'm just trying to understand why, historically, 
rq_daddr was just the 32-bit address and not a full sockaddr to begin 
with.  There may be something we're missing, like "we didn't want to add 
another large field to this structure due to memory alignment or 
allocation efficiency concerns".  :-)

> In fact, why isn't rq_daddr defined to be a sockaddr_storage so that it
> can be safely cast into either a sockaddr_in or a sockaddr_in6 after
> checking the ss_family field?

That isn't unreasonable, but see above.

Note also we have the same problem with NLM_REBOOT (see 
nlmsvc_decode_reboot() and nlmsvc_proc_sm_notify()).  These pass and 
store a 32-bit network-endian address rather than constructing a full 
sockaddr.  A similar solution invites itself.

[-- Attachment #2: chuck.lever.vcf --]
[-- Type: text/x-vcard, Size: 259 bytes --]

begin:vcard
fn:Chuck Lever
n:Lever;Chuck
org:Oracle Corporation;Corporate Architecture: Linux Projects Group
adr:;;1015 Granger Avenue;Ann Arbor;MI;48104;USA
title:Principal Member of Staff
tel;work:+1 248 614 5091
x-mozilla-html:FALSE
version:2.1
end:vcard


[-- Attachment #3: Type: text/plain, Size: 314 bytes --]

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

[-- Attachment #4: Type: text/plain, Size: 140 bytes --]

_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs