From: Trond Myklebust Subject: Re: [PATCH] nfs: Fix misparsing of nfsv4 fs_locations attribute Date: Tue, 20 May 2008 15:32:14 -0400 Message-ID: <1211311935.23156.15.camel@localhost> References: <20080509152750.GA325@fieldses.org> <20080509165204.GB1907@fieldses.org> <20080509171208.GC1907@fieldses.org> <20080509235930.GM1907@fieldses.org> <1210440728.12927.5.camel@localhost> <5FE6354F-8E28-4697-A27D-8532FD547683@oracle.com> <1d07ca700805101807s7c034b08sc531993aa81010b2@mail.gmail.com> <20080516195326.GD14228@fieldses.org> <20080520024734.GA23457@fieldses.org> Mime-Version: 1.0 Content-Type: text/plain Cc: "J. Bruce Fields" , "david m. richter" , linux-nfs@vger.kernel.org, Manoj Naik To: Chuck Lever Return-path: Received: from pat.uio.no ([129.240.10.15]:48090 "EHLO pat.uio.no" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757001AbYETTcZ (ORCPT ); Tue, 20 May 2008 15:32:25 -0400 In-Reply-To: Sender: linux-nfs-owner@vger.kernel.org List-ID: On Tue, 2008-05-20 at 12:54 -0400, Chuck Lever wrote: > So, I haven't added IPv6 support in this area because it seems to > assume an IPv4 address here, and it needs to handle the case where > this might be a hostname (ie there should be a DNS resolution in this > path). > > If you're going to call in4_pton(), it really should call > nfs_parse_server_address() instead; then this path would magically > support IPv6 addresses as well. > > But in the long run, this path will need either an upcall or it will > have to use the key-based kernel DNS resolution facility (Jeff Layton > mentioned something like this over lunch last week). No. The correct way to do this is to replace the current code fs_locations handler so that we do the mount from userspace. In addition to voiding the whole issue of in-kernel DNS resolution, that also has the benefit that it allows us to put policy decisions like which server to mount from under administrator control in userspace. I've already started coding up a solution. Trond