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. -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html