On Oct 1, 2008, at Oct 1, 2008, 4:08 PM, J. Bruce Fields wrote:
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?
Yes, our rpc.statd and lockd should agree on the contents and
interpretation of the opaque field. The field is opaque because it's
internal content is not defined by a standard. It's a cookie, just
like a file handle.
I would certainly *prefer* the use of an entirely arbitrary cookie,
but that's not the way Linux happens to work today.
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.
--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com
--
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
