> On Jan 23, 2023, at 11:07 AM, David Wysochanski <dwysocha@xxxxxxxxxx> wrote: > > On Mon, Jan 23, 2023 at 9:48 AM Chuck Lever III <chuck.lever@xxxxxxxxxx> wrote: >> >> Hi DW - >> >>> On Jan 23, 2023, at 8:52 AM, David Wysochanski <dwysocha@xxxxxxxxxx> wrote: >>> >>> On Wed, Nov 9, 2022 at 8:58 AM Chuck Lever III <chuck.lever@xxxxxxxxxx> wrote: >>>> >>>> >>>> >>>>> On Nov 9, 2022, at 8:33 AM, Dave Wysochanski <dwysocha@xxxxxxxxxx> 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 <chuck.lever@xxxxxxxxxx> >>>> >>> 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. > >> >>> I am not sure if you mean this should be applied or not. >> >> Reviewed-by: means "OK to apply". The documentation is incorrect. >> > Ok. > >> >>> 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. >>>>> Fixes: a28faaddb2be ("Documentation: Add an explanation of NFSv4 client identifiers") >>>>> Signed-off-by: Dave Wysochanski <dwysocha@xxxxxxxxxx> >>>>> --- >>>>> 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
