On Wed, Oct 01, 2008 at 03:40:05PM -0400, Chuck Lever wrote: > On Oct 1, 2008, at Oct 1, 2008, 2:18 PM, J. Bruce Fields wrote: >> On Wed, Oct 01, 2008 at 12:17:02PM -0400, Chuck Lever wrote: >>> On Sep 26, 2008, at Sep 26, 2008, 7:09 PM, J. Bruce Fields wrote: >>>> On Wed, Sep 17, 2008 at 11:18:11AM -0500, Chuck Lever wrote: >>>>> The XDR decoders for the NSM NOTIFY procedure should construct a >>>>> full >>>>> socket address and store it in the nlm_reboot structure. In >>>>> addition >>>>> to being able to store larger addresses, this means upper layer >>>>> routines get an address family tag so they can distinguish between >>>>> AF_INET and AF_INET6 addresses. >>>>> >>>>> This also keeps potentially large socket addresses off the stack >>>>> and >>>>> instead in dynamically allocated storage. >>>> >>>> So one way to think of this would be that you're extending the >>>> kernel<->statd interface by using the address family of statd's >>>> notify >>>> call to communicate the address family of the host that rebooted. >>>> >>>> Do I have that right? >>> >>> For statd, we're using the same technique that we used when >>> constructing >>> the source address in nlmsvc_lookup_host(). There's no family tag >>> associated with the address because the 16-byte opaque in the on- >>> the-wire >>> format has room only for the sin6_addr part of the address. >> >> OK. It seems a bit tricky, but I can't see why it doesn't work. > > Right. I couldn't think of something simpler. > > rpc.statd has to continue to work with legacy kernels where the first 4 > bytes of the opaque are a 32-bit sin_addr field and the following 12 > bytes are zero. Wait a minute, there's something not right there: rpc.statd shouldn't interpret the contents of the opaque field at all, should it? --b. > Apparently you can have a valid IPv6 address that looks > like that, but I can't find anything that states this conclusively. > > The kernel needs to know the address family in order to interpret the > contents of the opaque and turn them back into a sockaddr so it can be > matched against an nlm_host. -- 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
