From mboxrd@z Thu Jan 1 00:00:00 1970 From: "J. Bruce Fields" Subject: Re: [PATCH 08/10] lockd: struct nlm_reboot should contain a full socket address Date: Wed, 1 Oct 2008 17:30:02 -0400 Message-ID: <20081001213002.GK10937@fieldses.org> References: <20080917161811.4963.60224.stgit@ellison.1015granger.net> <20080926230938.GK7138@fieldses.org> <20081001181801.GF6001@fieldses.org> <59C7F69A-58EA-41F9-888E-C11039302755@oracle.com> <20081001200839.GB10937@fieldses.org> <20081001203305.GD10937@fieldses.org> <33D15870-F84F-42BE-B938-C792BC86B174@oracle.com> <20081001205520.GH10937@fieldses.org> <5E077AB6-2389-44A3-BC67-67CC08586FEB@oracle.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: linux-nfs@vger.kernel.org To: Chuck Lever Return-path: Received: from mail.fieldses.org ([66.93.2.214]:49701 "EHLO fieldses.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753236AbYJAVaE (ORCPT ); Wed, 1 Oct 2008 17:30:04 -0400 In-Reply-To: <5E077AB6-2389-44A3-BC67-67CC08586FEB@oracle.com> Sender: linux-nfs-owner@vger.kernel.org List-ID: On Wed, Oct 01, 2008 at 05:16:45PM -0400, Chuck Lever wrote: > > On Oct 1, 2008, at Oct 1, 2008, 4:55 PM, J. Bruce Fields wrote: > >> On Wed, Oct 01, 2008 at 04:48:41PM -0400, Chuck Lever wrote: >>> On Oct 1, 2008, at Oct 1, 2008, 4:33 PM, J. Bruce Fields wrote: >>>> And from a quick look at nfs-utils/statd/ it certainly looks to me >>>> like >>>> it's correctly treating the contents as a totally opaque object. >>> >>> That's exactly what happens. The cookie field is generated by the >>> SM_MON upcall, and passed back by the SM_NOTIFY downcall. >> >> OK, that's great. So we can just >> >> - Choose whatever contents for the "priv"/cookie field we want >> to keep the lookup on receipt of SM_NOTIFY easy, and >> - remove the support for ipv6 on the loopback communication >> with statd; we don't need it. > > I agree that since lockd generates the cookies, we can be smarter about > how lockd deals with cookies coming back from statd, and I strongly > prefer an approach that treats the opaques as arbitrary rather than > interpreted values. > > I think we may need to keep some IPv6 support in lockd for loopback down > calls. On an AF_INET6 listener socket, loopback calls will come from the > IPv6 loopback address, AFAICT, even if they are sent from user space via > the IPv4 loopback address. The kernel's network layer will map the IPv4 > loopback address to the IPv6 loopback address automatically. OK. (Well, I guess we could do whatever we'd like here, including using a separate socket and even program for the notification downcall, but doing what you propose is probably simplest.) > I am working on revising last week's patch set based on your comments. I > plan to repost an updated version of these soon, but I can leave out the > last two or three patches that deal solely with the mechanics of these > NSM-related cookies. Sounds fine, thanks! --b.