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:     "Trond Myklebust" <trondmy@hammerspace.com>
Cc:     neilb@suse.de, linux-nfs@vger.kernel.org
Subject: Re: v4 clientid uniquifiers in containers/namespaces
Date:   Tue, 15 Feb 2022 11:57:37 -0500
Message-ID: <40A1C333-66AD-4866-90EF-B8A90AA58C82@redhat.com>
In-Reply-To: <06e2a692e587d1ffcccd14d465136df228149e4c.camel@hammerspace.com>
References: <6CEC5101-0512-4082-81F8-BDFEC5B6DF3A@redhat.com>
 <164428557862.27779.17375354328525752842@noble.neil.brown.name>
 <A677D8A9-FD0B-43E5-82D6-E660CCB8B185@redhat.com>
 <164435376000.27779.4059629372785561121@noble.neil.brown.name>
 <06e2a692e587d1ffcccd14d465136df228149e4c.camel@hammerspace.com>
MIME-Version: 1.0
Content-Type: text/plain
Precedence: bulk

On 8 Feb 2022, at 18:34, Trond Myklebust wrote:

> On Wed, 2022-02-09 at 07:56 +1100, NeilBrown wrote:

>> So I still STRONGLY think that the identity should be set by
>> mount.nfs
>> reading (and writing) some file in /etc or /etc/netnfs/NAME, and I
>> weakly think that the file should be in /etc/nfs.conf.d/ so that the
>> reading is automagic.
>>
>
> No. It's not a per-mount setting, so it has no business being in the
> mount protocol.

Trond,

We still have the issue that udev handling the event to set the uniquifier
for the init namespace races with the first SETCLIENTID/EXCHANGE_ID.

Now that network namespaces uniqify by default, would you prefer we try to
solve this with the userspace tools setting the module parameter instead of
depending on udev for the init namespace?

Alternatively, we could grow another module parameter:
nfs4_unique_id_timeout:int Seconds to wait for a uniquifier

A non-zero default also gives network namespaces the chance to set a
persistent value that differs from the random value the kernel generated.

Ben