Received-SPF: pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
From:   "Benjamin Coddington" <bcodding@redhat.com>
To:     "Chuck Lever III" <chuck.lever@oracle.com>
Cc:     "Trond Myklebust" <trondmy@hammerspace.com>,
        "Linux NFS Mailing List" <linux-nfs@vger.kernel.org>
Subject: Re: v4 clientid uniquifiers in containers/namespaces
Date:   Tue, 08 Feb 2022 10:23:21 -0500
Message-ID: <6AB99AB0-A9A5-4000-BABD-8EFC34FC31D5@redhat.com>
In-Reply-To: <6211BF2A-2A00-4E00-8647-57D829D41E8D@oracle.com>
References: <6CEC5101-0512-4082-81F8-BDFEC5B6DF3A@redhat.com>
 <6ac83db82e838d9d4e1ac10cb13e43c5c12b2660.camel@hammerspace.com>
 <439C77F9-D5AD-4388-B954-3B413C1DF0E2@redhat.com>
 <596C2475-76AA-4616-919C-9C22B6658CA7@redhat.com>
 <DB8B60C8-B772-4604-A841-47F789723D5D@oracle.com>
 <b192022ce73ea690a117d7710b492e83be99df31.camel@hammerspace.com>
 <43990B9C-013C-4E77-AADA-F274ACBE4757@oracle.com>
 <8CCCD806-A467-432C-B7FF-9E83981533EF@redhat.com>
 <c9948f895e91abb76a21609bf629b88bbfcf4d9a.camel@hammerspace.com>
 <CEC36879-0474-44A1-984B-BAE69C168274@redhat.com>
 <6211BF2A-2A00-4E00-8647-57D829D41E8D@oracle.com>
MIME-Version: 1.0
Content-Type: text/plain; format=flowed
Precedence: bulk

On 8 Feb 2022, at 9:42, Chuck Lever III wrote:

>> On Feb 8, 2022, at 9:29 AM, Benjamin Coddington <bcodding@redhat.com> 
>> wrote:
>>
>> On 8 Feb 2022, at 8:45, Trond Myklebust wrote:
>>
>>>> Can't we just uniquify the namespaced NFS client ourselves, while
>>>> still
>>>> exposing /sys/fs/nfs/net/nfs_client/identifier within the 
>>>> namespace?
>>>> That
>>>> way if someone want to run udev or use their own method of 
>>>> persistent
>>>> id
>>>> its available to them within the container so they can.  Then we 
>>>> can
>>>> move
>>>> forward because the problem of distinguishing clients between the
>>>> host
>>>> and
>>>> netns is automagically solved.
>>>
>>> That could be done.
>>
>> Ok, I'm eyeballing a sha1 of the init namespace uniquifier and
>> peernet2id_alloc(new_net, init_net).. but means the NFS client would 
>> grow a
>> dependency on CRYPTO and CRYPTO_SHA1.
>
> Or you could use siphash instead of SHA-1.
>
> I don't think we should be adding any more SHA-1 to the kernel --
> it's deprecated for good reasons.

Thanks! Siphash is nicer too.  :)

Ben