Received-SPF: pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0
From:   "NeilBrown" <neilb@suse.de>
To:     "Benjamin Coddington" <bcodding@redhat.com>
Cc:     "Linux NFS Mailing List" <linux-nfs@vger.kernel.org>
Subject: Re: v4 clientid uniquifiers in containers/namespaces
In-reply-to: <6CEC5101-0512-4082-81F8-BDFEC5B6DF3A@redhat.com>
References: <6CEC5101-0512-4082-81F8-BDFEC5B6DF3A@redhat.com>
Date:   Tue, 08 Feb 2022 12:59:38 +1100
Message-id: <164428557862.27779.17375354328525752842@noble.neil.brown.name>
Precedence: bulk

On Sun, 06 Feb 2022, Benjamin Coddington wrote:
> Hi all,
> 
> Is anyone using a udev(-like) implementation with NETLINK_LISTEN_ALL_NSID?
> It looks like that is at least necessary to allow the init namespaced udev
> to receive notifications on /sys/fs/nfs/net/nfs_client/identifier, which
> would be a pre-req to automatically uniquify in containers.

Could you walk me through the reasoning here - or point me to where it
has been discussed.
It seems to me that mount.nfs is the place to set nfs_client/identifier.
It can be told (via /etc/nfs.conf or /etc/nfsmount.conf) how to generate
and where to store the identifier.  It can check the current value and
update if needed.  As long as the identifier is set before the first
mount, there is no rush.

Why does it need to be done in response to a uevent??

Thanks,
NeilBrown