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 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.