Re: [PATCH 08/10] lockd: struct nlm_reboot should contain a full socket address

["J. Bruce Fields" <bfields@fieldses.org>]

On Wed, Oct 01, 2008 at 04:08:39PM -0400, bfields 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?

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.

So I think we can put whatever we want in the priv field--an ipv6
address, an index into some kernel table, whatever.  (The priv field
shouldn't even have to make sense to a future boot instance--we don't
need to be notified of previously monitored hosts' reboots any more once
we've rebooted ourselves.)

--b.