From mboxrd@z Thu Jan 1 00:00:00 1970 From: Chuck Lever Subject: Re: Use of delayed request information in nlmsvc_lookup_host Date: Thu, 15 Nov 2007 13:02:23 -0500 Message-ID: <473C89AF.8020707@oracle.com> References: <473B3D0B.3060204@oracle.com> <1195065798.7584.37.camel@heimdal.trondhjem.org> <473B45C9.4060708@oracle.com> <1195069262.7584.54.camel@heimdal.trondhjem.org> <473B5278.7090408@oracle.com> <18235.41907.383911.722103@notabene.brown> <473C4FE2.1090402@oracle.com> <1195142050.7506.13.camel@heimdal.trondhjem.org> <473C80A2.1020204@oracle.com> <1195148262.7673.11.camel@heimdal.trondhjem.org> Reply-To: chuck.lever@oracle.com Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="------------020205010000000009080409" Cc: Neil Brown , nfs@lists.sourceforge.net To: Trond Myklebust Return-path: Received: from sc8-sf-mx1-b.sourceforge.net ([10.3.1.91] helo=mail.sourceforge.net) by sc8-sf-list2-new.sourceforge.net with esmtp (Exim 4.43) id 1Isj3d-00013k-0h for nfs@lists.sourceforge.net; Thu, 15 Nov 2007 10:03:17 -0800 Received: from agminet01.oracle.com ([141.146.126.228]) by mail.sourceforge.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44) id 1Isj3f-00028o-Jd for nfs@lists.sourceforge.net; Thu, 15 Nov 2007 10:03:22 -0800 In-Reply-To: <1195148262.7673.11.camel@heimdal.trondhjem.org> List-Id: "Discussion of NFS under Linux development, interoperability, and testing." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: nfs-bounces@lists.sourceforge.net Errors-To: nfs-bounces@lists.sourceforge.net This is a multi-part message in MIME format. --------------020205010000000009080409 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Trond Myklebust wrote: > On Thu, 2007-11-15 at 12:23 -0500, Chuck Lever wrote: >> Trond Myklebust wrote: >>> On Thu, 2007-11-15 at 08:55 -0500, Chuck Lever wrote: >>> >>>> What do you think of changing the rq_daddr field to be a sockaddr_storage? >>> Why? You've already got rq_addr. >> OK, here's what I've ended up with. I think this is what you and Neil >> have been suggesting. Comments? >> >> /* >> * Find an NLM client handle in the cache. If there is none, create it. >> * >> * Manufacture a specific source address in case we're using multiple >> * IP addresses on a single NIC. NB: the family of the address in >> * rq_daddr is guaranteed to be the same as the family of rq_addr. >> */ >> struct nlm_host * >> nlmsvc_lookup_host(struct svc_rqst *rqstp, >> const char *hostname, unsigned int hostname_len) >> { >> struct sockaddr_in6 source = { >> .sin6_family = AF_INET6, >> }; >> >> switch(svc_addr(rqstp)->sa_family) { >> case AF_INET: { >> struct sockaddr_in *sin = (struct sockaddr_in *)&source; >> sin->sin_family = AF_INET; >> sin->sin_addr.s_addr = rqstp->rq_daddr.addr.s_addr; >> break; >> } >> case AF_INET6: >> ipv6_addr_copy(&source.sin6_addr, >> &rqstp->rq_daddr.addr6); >> break; >> } >> >> return nlm_lookup_host(1, svc_addr_in(rqstp), >> rqstp->rq_prot, rqstp->rq_vers, >> hostname, hostname_len, >> (struct sockaddr *)&source); >> } > > That works for me. Technically, I suppose we should really pass a > source_len to nlm_lookup_host() if only to ensure that the comparisons > don't overrun memory, however in practice I doubt this is a problem. We > always know that the kernel allocates enough space. My IPv6-aware version of nlm_cmp_addr takes a pair of sockaddr *'s; no lengths are needed for the comparison of either AF_INET or AF_INET6 addresses. In fact, in most cases, it appears that the address length is unneeded for us. Both INET families use fixed-size addresses. --------------020205010000000009080409 Content-Type: text/x-vcard; charset=utf-8; name="chuck.lever.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="chuck.lever.vcf" 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 --------------020205010000000009080409 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline ------------------------------------------------------------------------- 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/ --------------020205010000000009080409 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ NFS maillist - NFS@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nfs --------------020205010000000009080409--