public inbox for linux-nfs@vger.kernel.org
 help / color / mirror / Atom feed
From: "Pali Rohár" <pali@kernel.org>
To: Chuck Lever III <chuck.lever@oracle.com>
Cc: Neil Brown <neilb@suse.de>, Jeff Layton <jlayton@kernel.org>,
	Olga Kornievskaia <okorniev@redhat.com>,
	Dai Ngo <dai.ngo@oracle.com>, Tom Talpey <tom@talpey.com>,
	Linux NFS Mailing List <linux-nfs@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] lockd: Fix comment about NLMv3 backwards compatibility
Date: Sat, 5 Oct 2024 19:56:44 +0200	[thread overview]
Message-ID: <20241005175644.usygr3set3txtu76@pali> (raw)
In-Reply-To: <01C90EC0-1C3E-4880-9D33-ADCDA5B35483@oracle.com>

On Saturday 05 October 2024 17:52:13 Chuck Lever III wrote:
> > On Oct 5, 2024, at 12:51 PM, Pali Rohár <pali@kernel.org> wrote:
> > 
> > On Thursday 12 September 2024 19:34:02 Chuck Lever wrote:
> >> On Fri, Sep 13, 2024 at 01:28:20AM +0200, Pali Rohár wrote:
> >>> On Friday 13 September 2024 01:22:07 Pali Rohár wrote:
> >>>> On Friday 13 September 2024 09:10:45 NeilBrown wrote:
> >>>>> On Fri, 13 Sep 2024, Pali Rohár wrote:
> >>>>>> NLMv2 is completely different protocol than NLMv1 and NLMv3, and in
> >>>>>> original Sun implementation is used for RPC loopback callbacks from statd
> >>>>>> to lockd services. Linux does not use nor does not implement NLMv2.
> >>>>>> 
> >>>>>> Hence, NLMv3 is not backward compatible with NLMv2. But NLMv3 is backward
> >>>>>> compatible with NLMv1. Fix comment.
> >>>>>> 
> >>>>>> Signed-off-by: Pali Rohár <pali@kernel.org>
> >>>>>> ---
> >>>>>> fs/lockd/clntxdr.c | 4 +++-
> >>>>>> 1 file changed, 3 insertions(+), 1 deletion(-)
> >>>>>> 
> >>>>>> diff --git a/fs/lockd/clntxdr.c b/fs/lockd/clntxdr.c
> >>>>>> index a3e97278b997..81ffa521f945 100644
> >>>>>> --- a/fs/lockd/clntxdr.c
> >>>>>> +++ b/fs/lockd/clntxdr.c
> >>>>>> @@ -3,7 +3,9 @@
> >>>>>>  * linux/fs/lockd/clntxdr.c
> >>>>>>  *
> >>>>>>  * XDR functions to encode/decode NLM version 3 RPC arguments and results.
> >>>>>> - * NLM version 3 is backwards compatible with NLM versions 1 and 2.
> >>>>>> + * NLM version 3 is backwards compatible with NLM version 1.
> >>>>>> + * NLM version 2 is different protocol used only for RPC loopback callbacks
> >>>>>> + * from statd to lockd and is not implemented on Linux.
> >>>>>>  *
> >>>>>>  * NLM client-side only.
> >>>>>>  *
> >>>>> 
> >>>>> Reviewed-by: NeilBrown <neilb@suse.de>
> >>>>> 
> >>>>> Do you have a reference for that info about v2?  I hadn't heard of it
> >>>>> before.
> >>>>> 
> >>>>> NeilBrown
> >>>> 
> >>>> I have just this information in my notes. I guess it should be possible
> >>>> to gather more information about v2 from released Sun/Solaris source
> >>>> code via OpenSolaris / Illumos projects.
> >>> 
> >>> Just very quickly I found this Illumos XDR file for NLM:
> >>> https://github.com/illumos/illumos-gate/blob/master/usr/src/uts/common/rpcsvc/nlm_prot.x
> >>> 
> >>> And it defines NLMv2 with two procedures numbered 17 and 18, plus there
> >>> is a comment in file header about v2.
> >>> 
> >>> So probably the best reference would be the Illumos source code.
> >> 
> >> What you see in the Illumos code is not something that is part
> >> of the standard NLM protocol, but rather a private upcall protocol
> >> between the kernel and user space that is special sauce added
> >> by each implementation of NLM/NSM.
> > 
> > Ok. But this applies for v2, no?
> 
> On Linux, those operations are part of the NLMv1/3/4
> protocol implementation, so essentially the NLM v2
> functionality is a part of all NLM versions on Linux.
> 
> 
> >> Also note the way NLMv3 is defined in this file: it defines only
> >> a handful of new operations. The other operations are inherited
> >> from NLMv1.
> > 
> > Yes, v3 is there and is inherited from v1. This is also what I pointed
> > in the comment. That v3 inherits from v1, not v2.
> 
> Generally this is an abuse of the purpose of the RPC
> program versioning mechanism. Linux has a very similar
> upcall mechanism, but uses NLM procedure numbers that
> are set aside for this purpose instead of abusing a
> moribund protocol version.

I agree that this abuse of the versioning scheme. But it is there and
used in this way for a very long time.

> 
> > In header file of that nlm_prot.x is written:
> > 
> > * There are currently 3 versions of the protocol in use.  Versions 1
> > * and 3 are used with NFS version 2.  Version 4 is used with NFS
> > * version 3.
> > *
> > * (Note: there is also a version 2, but it defines an orthogonal set of
> > * procedures that the status monitor uses to notify the lock manager of
> > * changes in monitored systems.)
> > 
> > Which sounds like version 3 has nothing with version 2.
> > 
> > My understanding of that comment is that version 2 contains only those
> > private upcall protocol between kernel and userspace about which you
> > wrote, and therefore version 3 is not backward compatible with version 2.
> > 
> >> IMO the comment is accurate and does not warrant a change.
> 
> How about this replacement:
> 
>  * XDR functions to encode/decode NLM version 1 and 3 RPC
>  * arguments and results. NLM version 2 is not specified
>  * by a standard, thus it is not implemented.

That is perfect! Covers everything.

  reply	other threads:[~2024-10-05 17:56 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-09-12 22:53 [PATCH] lockd: Fix comment about NLMv3 backwards compatibility Pali Rohár
2024-09-12 23:10 ` NeilBrown
2024-09-12 23:22   ` Pali Rohár
2024-09-12 23:28     ` Pali Rohár
2024-09-12 23:34       ` Chuck Lever
2024-10-05 16:51         ` Pali Rohár
2024-10-05 17:52           ` Chuck Lever III
2024-10-05 17:56             ` Pali Rohár [this message]
2024-10-18 13:38 ` cel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20241005175644.usygr3set3txtu76@pali \
    --to=pali@kernel.org \
    --cc=chuck.lever@oracle.com \
    --cc=dai.ngo@oracle.com \
    --cc=jlayton@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-nfs@vger.kernel.org \
    --cc=neilb@suse.de \
    --cc=okorniev@redhat.com \
    --cc=tom@talpey.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox