All of lore.kernel.org
 help / color / mirror / Atom feed
From: Chuck Lever III <chuck.lever@oracle.com>
To: Trond Myklebust <trondmy@hammerspace.com>
Cc: Linux NFS Mailing List <linux-nfs@vger.kernel.org>,
	Bruce Fields <bfields@redhat.com>,
	"trondmy@kernel.org" <trondmy@kernel.org>
Subject: Re: [PATCH v2 10/10] nfsd: Ignore rpcbind errors on nfsd startup
Date: Mon, 20 Dec 2021 19:02:11 +0000	[thread overview]
Message-ID: <753AE969-5C7E-4BA7-8CA4-003671710DAC@oracle.com> (raw)
In-Reply-To: <9679c6f76f751c6c379bcfb889fd1dcba1671eac.camel@hammerspace.com>



> On Dec 20, 2021, at 1:35 PM, Trond Myklebust <trondmy@hammerspace.com> wrote:
> 
> On Mon, 2021-12-20 at 15:51 +0000, Chuck Lever III wrote:
>> 
>> 
>>> On Dec 19, 2021, at 3:49 PM, Trond Myklebust
>>> <trondmy@hammerspace.com> wrote:
>>> 
>>> On Sun, 2021-12-19 at 18:15 +0000, Chuck Lever III wrote:
>>>> 
>>>>> On Dec 18, 2021, at 8:38 PM, trondmy@kernel.org wrote:
>>>>> 
>>>>> From: Trond Myklebust <trond.myklebust@hammerspace.com>
>>>>> 
>>>>> NFSv4 doesn't need rpcbind, so let's not refuse to start up
>>>>> just
>>>>> because
>>>>> the rpcbind registration failed.
>>>> 
>>>> Commit 7e55b59b2f32 ("SUNRPC/NFSD: Support a new option for
>>>> ignoring
>>>> the result of svc_register") added vs_rpcb_optnl, which is
>>>> already
>>>> set for nfsd4_version4. Is that not adequate?
>>>> 
>>> 
>>> The other issue is that under certain circumstances, you may also
>>> want
>>> to run NFSv3 without rpcbind support. For instance, when you have a
>>> knfsd server instance running as a data server, there is typically
>>> no
>>> need to run rpcbind.
>> 
>> So what you are saying is that you'd like this to be a run-time
>> setting
>> instead of a compile-time setting. Got it.
>> 
>> Note that this patch adds a non-container-aware administrative API.
>> For
>> the same reasons I NAK'd 9/10, I'm going to NAK this one and ask that
>> you provide a version that is container-aware (ideally: not a module
>> parameter).
>> 
>> The new implementation should remove vs_rpcb_optnl, as a clean up.
>> 
>> 
> 
> This is not something that turns off the registration with rpcbind. It
> is something that turns off the decision to abort knfsd if that
> registration fails.

See below, that's just what vs_rpcb_optnl does. It it's true,
then the result of the rpcbind registration for that service
is ignored.

1039 int svc_generic_rpcbind_set(struct net *net,
1040                             const struct svc_program *progp,
1041                             u32 version, int family,
1042                             unsigned short proto,
1043                             unsigned short port)
1044 {
1045         const struct svc_version *vers = progp->pg_vers[version];
1046         int error;
1047 
1048         if (vers == NULL)
1049                 return 0;
1050 
1051         if (vers->vs_hidden) {
1052                 trace_svc_noregister(progp->pg_name, version, proto,
1053                                      port, family, 0);
1054                 return 0;
1055         }
1056 
1057         /*
1058          * Don't register a UDP port if we need congestion
1059          * control.
1060          */
1061         if (vers->vs_need_cong_ctrl && proto == IPPROTO_UDP)
1062                 return 0;
1063 
1064         error = svc_rpcbind_set_version(net, progp, version,
1065                                         family, proto, port);
1066 
1067         return (vers->vs_rpcb_optnl) ? 0 : error;
1068 }
1069 EXPORT_SYMBOL_GPL(svc_generic_rpcbind_set);

And, it's already the case that vs_rpcb_optnl is true for our
NFSv4 server. So the issue is for NFSv3 only. It still looks
to me like the patch description for this patch, at the very
least, is not correct.


> That's not something that needs to be
> containerised: it's just common sense and really wants to be the
> default behaviour everywhere.

I'm not following this. I can imagine deployment cases where one
container might want to ensure rpcbind is running for NFSv3 while
another does not care. What am I missing?


> The only reason for the module parameter is to enable legacy behaviour.


--
Chuck Lever




  reply	other threads:[~2021-12-20 19:02 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-19  1:37 [PATCH v2 00/10] Assorted patches for knfsd trondmy
2021-12-19  1:37 ` [PATCH v2 01/10] nfsd: map EBADF trondmy
2021-12-19  1:37   ` [PATCH v2 02/10] nfsd: Add errno mapping for EREMOTEIO trondmy
2021-12-19  1:37     ` [PATCH v2 03/10] nfsd: Retry once in nfsd_open on an -EOPENSTALE return trondmy
2021-12-19  1:37       ` [PATCH v2 04/10] nfsd: Distinguish between required and optional NFSv3 post-op attributes trondmy
2021-12-19  1:37         ` [PATCH v2 05/10] nfs: Add export support for weak cache consistency attributes trondmy
2021-12-19  1:37           ` [PATCH v2 06/10] nfsd: NFSv3 should allow zero length writes trondmy
2021-12-19  1:38             ` [PATCH v2 07/10] nfsd: Add a tracepoint for errors in nfsd4_clone_file_range() trondmy
2021-12-19  1:38               ` [PATCH v2 08/10] nfsd: Replace use of rwsem with errseq_t trondmy
2021-12-19  1:38                 ` [PATCH v2 09/10] nfsd: allow lockd to be forcibly disabled trondmy
2021-12-19  1:38                   ` [PATCH v2 10/10] nfsd: Ignore rpcbind errors on nfsd startup trondmy
2021-12-19 18:15                     ` Chuck Lever III
2021-12-19 20:49                       ` Trond Myklebust
2021-12-20 15:51                         ` Chuck Lever III
2021-12-20 18:35                           ` Trond Myklebust
2021-12-20 19:02                             ` Chuck Lever III [this message]
2021-12-20 19:52                               ` Trond Myklebust
2021-12-20 20:12                                 ` Chuck Lever III
2021-12-19 18:34                   ` [PATCH v2 09/10] nfsd: allow lockd to be forcibly disabled Chuck Lever III
2021-12-21 18:14               ` [PATCH v2 07/10] nfsd: Add a tracepoint for errors in nfsd4_clone_file_range() Chuck Lever III
2021-12-19 20:11             ` [PATCH v2 06/10] nfsd: NFSv3 should allow zero length writes Chuck Lever III
2022-01-05 16:10           ` [PATCH v2 05/10] nfs: Add export support for weak cache consistency attributes Daire Byrne
2021-12-19 20:10         ` [PATCH v2 04/10] nfsd: Distinguish between required and optional NFSv3 post-op attributes Chuck Lever III
2021-12-19 21:09           ` Trond Myklebust
2021-12-20 16:02             ` Chuck Lever III
2021-12-20 18:38               ` Trond Myklebust
2021-12-20 19:22                 ` Chuck Lever III
2021-12-21 18:10 ` [PATCH v2 00/10] Assorted patches for knfsd Chuck Lever III

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=753AE969-5C7E-4BA7-8CA4-003671710DAC@oracle.com \
    --to=chuck.lever@oracle.com \
    --cc=bfields@redhat.com \
    --cc=linux-nfs@vger.kernel.org \
    --cc=trondmy@hammerspace.com \
    --cc=trondmy@kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.