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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Index of Archives]     [Linux Filesystem Development]     [Linux USB Development]     [Linux Media Development]     [Video for Linux]     [Linux NILFS]     [Linux Audio Users]     [Yosemite Info]     [Linux SCSI]

  Powered by Linux