On Jan 23, 2023, at 11:07 AM, David Wysochanski [off-list ref] wrote:

On Mon, Jan 23, 2023 at 9:48 AM Chuck Lever III [off-list ref] wrote:

quoted

Hi DW -

quoted

On Jan 23, 2023, at 8:52 AM, David Wysochanski [off-list ref] wrote:

On Wed, Nov 9, 2022 at 8:58 AM Chuck Lever III [off-list ref] wrote:

quoted

quoted

On Nov 9, 2022, at 8:33 AM, Dave Wysochanski [off-list ref] wrote:

The sysfs path for the NFS4 client identfier should start with
the path component of 'nfs' for the kset, and then the 'net'
path component for the netns object, followed by the
'nfs_client' path component for the NFS client kobject,
and ending with 'identifier' for the netns_client_id
kobj_attribute.

Seems like the redundancy has some purpose and is baked-in to
the path. I'd rather leave the sleeping dog as it is, enjoying
the morning sun.

Reviewed-by: Chuck Lever <redacted>

Hey Chuck,

I just realized the patch is still outstanding.  Now when I re-read
your comment, I'm not sure what it means.  Your comment sounds
like you feel the patch may not be necessary, but then you have
a "Reviewed-by".

I was responding to Ben's suggestion elsewhere that the pathname
had redundant components and should be simplified. After reviewing
the code (and your patch) it appears that all the components are
necessary to have, so the document change you proposed is
appropriate.

Ah ok yes I remember now, thanks for explaining.

quoted

quoted

I am not sure if you mean this should be applied or not.

Reviewed-by: means "OK to apply". The documentation is incorrect.

Ok.

quoted

quoted

To be clear, the existing sysfs path does not exist, and we got a
complaint about this documentation inaccuracy, hence my patch.

Can you dig up the complaint bug and suggest a Link: tag to add?

It was such a small issue I was not planning to create a separate
bug, but I can do so easily if you would like that.

The comment was a private comment that came later on in this
bug, which you commented on a while back when there was discussion
on how to generate a unique id.
https://bugzilla.redhat.com/show_bug.cgi?id=1801326#c45
The bug was repurposed to documentation only.

Link: https://bugzilla.redhat.com/show_bug.cgi?id=1801326

seems appropriate to me.

quoted

quoted

quoted

quoted

Fixes: a28faaddb2be ("Documentation: Add an explanation of NFSv4 client identifiers")
Signed-off-by: Dave Wysochanski <redacted>
---
Documentation/filesystems/nfs/client-identifier.rst | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/Documentation/filesystems/nfs/client-identifier.rst b/Documentation/filesystems/nfs/client-identifier.rst
index 5147e15815a1..a94c7a9748d7 100644
--- a/Documentation/filesystems/nfs/client-identifier.rst
+++ b/Documentation/filesystems/nfs/client-identifier.rst

@@ -152,7 +152,7 @@ string:
    via the kernel command line, or when the "nfs" module is
    loaded.

-    /sys/fs/nfs/client/net/identifier
+    /sys/fs/nfs/net/nfs_client/identifier
    This virtual file, available since Linux 5.3, is local to the
    network namespace in which it is accessed and so can provide
    distinction between network namespaces (containers) when the

@@ -164,7 +164,7 @@ then that uniquifier can be used. For example, a uniquifier might

be formed at boot using the container's internal identifier:

  sha256sum /etc/machine-id | awk '{print $1}' \\
-        > /sys/fs/nfs/client/net/identifier
+        > /sys/fs/nfs/net/nfs_client/identifier

Security considerations
-----------------------
--
2.31.1

--
Chuck Lever

--
Chuck Lever

--
Chuck Lever