From: Chuck Lever <chuck.lever@oracle.com>
To: Mike Snitzer <snitzer@kernel.org>, Jeff Layton <jlayton@kernel.org>
Cc: Neil Brown <neilb@suse.de>,
Olga Kornievskaia <okorniev@redhat.com>,
Dai Ngo <Dai.Ngo@oracle.com>, Tom Talpey <tom@talpey.com>,
Steven Rostedt <rostedt@goodmis.org>,
Masami Hiramatsu <mhiramat@kernel.org>,
Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
Trond Myklebust <trondmy@kernel.org>,
Anna Schumaker <anna@kernel.org>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Simon Horman <horms@kernel.org>,
linux-nfs@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-trace-kernel@vger.kernel.org, netdev@vger.kernel.org
Subject: Re: [PATCH 1/2] nfsd: use threads array as-is in netlink interface
Date: Fri, 13 Jun 2025 15:00:57 -0400 [thread overview]
Message-ID: <6e7361b4-7511-4630-9f1b-d7968cbebd41@oracle.com> (raw)
In-Reply-To: <aEx0ocoWoFkp8oCg@kernel.org>
On 6/13/25 2:57 PM, Mike Snitzer wrote:
> On Thu, Jun 12, 2025 at 11:57:59AM -0400, Jeff Layton wrote:
>> On Tue, 2025-05-27 at 20:12 -0400, Jeff Layton wrote:
>>> The old nfsdfs interface for starting a server with multiple pools
>>> handles the special case of a single entry array passed down from
>>> userland by distributing the threads over every NUMA node.
>>>
>>> The netlink control interface however constructs an array of length
>>> nfsd_nrpools() and fills any unprovided slots with 0's. This behavior
>>> defeats the special casing that the old interface relies on.
>>>
>>> Change nfsd_nl_threads_set_doit() to pass down the array from userland
>>> as-is.
>>>
>>> Fixes: 7f5c330b2620 ("nfsd: allow passing in array of thread counts via netlink")
>>> Reported-by: Mike Snitzer <snitzer@kernel.org>
>>> Closes: https://lore.kernel.org/linux-nfs/aDC-ftnzhJAlwqwh@kernel.org/
>>> Signed-off-by: Jeff Layton <jlayton@kernel.org>
>>> ---
>>> fs/nfsd/nfsctl.c | 5 ++---
>>> 1 file changed, 2 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/fs/nfsd/nfsctl.c b/fs/nfsd/nfsctl.c
>>> index ac265d6fde35df4e02b955050f5b0ef22e6e519c..22101e08c3e80350668e94c395058bc228b08e64 100644
>>> --- a/fs/nfsd/nfsctl.c
>>> +++ b/fs/nfsd/nfsctl.c
>>> @@ -1611,7 +1611,7 @@ int nfsd_nl_rpc_status_get_dumpit(struct sk_buff *skb,
>>> */
>>> int nfsd_nl_threads_set_doit(struct sk_buff *skb, struct genl_info *info)
>>> {
>>> - int *nthreads, count = 0, nrpools, i, ret = -EOPNOTSUPP, rem;
>>> + int *nthreads, nrpools = 0, i, ret = -EOPNOTSUPP, rem;
>>> struct net *net = genl_info_net(info);
>>> struct nfsd_net *nn = net_generic(net, nfsd_net_id);
>>> const struct nlattr *attr;
>>> @@ -1623,12 +1623,11 @@ int nfsd_nl_threads_set_doit(struct sk_buff *skb, struct genl_info *info)
>>> /* count number of SERVER_THREADS values */
>>> nlmsg_for_each_attr(attr, info->nlhdr, GENL_HDRLEN, rem) {
>>> if (nla_type(attr) == NFSD_A_SERVER_THREADS)
>>> - count++;
>>> + nrpools++;
>>> }
>>>
>>> mutex_lock(&nfsd_mutex);
>>>
>>> - nrpools = max(count, nfsd_nrpools(net));
>>> nthreads = kcalloc(nrpools, sizeof(int), GFP_KERNEL);
>>> if (!nthreads) {
>>> ret = -ENOMEM;
>>
>> I noticed that this didn't go in to the recent merge window.
>>
>> This patch fixes a rather nasty regression when you try to start the
>> server on a NUMA-capable box. It all looks like it works, but some RPCs
>> get silently dropped on the floor (if they happen to be received into a
>> node with no threads). It took me a while to track down the problem
>> after Mike reported it.
>>
>> Can we go ahead and pull this in and send it to stable?
>>
>> Also, did this patch fix the problem for you, Mike?
>
> Hi Jeff,
>
> I saw your other mail asking the same, figured it best to reply to this
> thread with the patch.
>
> YES, I just verified this patch fixes the issue I reported. I didn't
> think I was critical path for confirming the fix, and since I had
> worked around it (by downgrading nfs-utils from EL10's 2.8.2 to EL9's
> 2.5.4 it wasn't a super quick thing for me to test.. it became
> out-of-sight-out-of-mind...
>
> BTW, Chuck, I think the reason there aren't many/any reports (even
> with RHEL10 or Fedora users) is that the user needs to:
> 1) have a NUMA system
> 2) explicitly change sunrpc's default for pool_mode from global to pernode.
Not a very common thing to do, IME.
> Anyway:
>
> Tested-by: Mike Snitzer <snitzer@kernel.org>
Tag applied, thanks.
--
Chuck Lever
next prev parent reply other threads:[~2025-06-13 19:01 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-28 0:12 [PATCH 0/2] nfsd: use threads array as-is in netlink thread set interface Jeff Layton
2025-05-28 0:12 ` [PATCH 1/2] nfsd: use threads array as-is in netlink interface Jeff Layton
2025-05-28 17:07 ` Simon Horman
2025-06-12 15:57 ` Jeff Layton
2025-06-12 16:05 ` Chuck Lever
2025-06-12 16:15 ` Jeff Layton
2025-06-12 16:42 ` Chuck Lever
2025-06-13 11:33 ` Benjamin Coddington
2025-06-13 14:56 ` Chuck Lever
2025-06-13 15:23 ` Benjamin Coddington
2025-06-13 15:38 ` Chuck Lever
2025-06-13 21:05 ` Jeff Layton
2025-06-13 18:57 ` Mike Snitzer
2025-06-13 19:00 ` Chuck Lever [this message]
2025-05-28 0:12 ` [PATCH 2/2] sunrpc: new tracepoints around svc thread wakeups Jeff Layton
2025-05-28 17:13 ` Simon Horman
2025-05-28 18:11 ` [PATCH 0/2] nfsd: use threads array as-is in netlink thread set interface cel
2025-05-28 18:22 ` Jeff Layton
2025-05-28 18:25 ` Chuck Lever
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=6e7361b4-7511-4630-9f1b-d7968cbebd41@oracle.com \
--to=chuck.lever@oracle.com \
--cc=Dai.Ngo@oracle.com \
--cc=anna@kernel.org \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=horms@kernel.org \
--cc=jlayton@kernel.org \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nfs@vger.kernel.org \
--cc=linux-trace-kernel@vger.kernel.org \
--cc=mathieu.desnoyers@efficios.com \
--cc=mhiramat@kernel.org \
--cc=neilb@suse.de \
--cc=netdev@vger.kernel.org \
--cc=okorniev@redhat.com \
--cc=pabeni@redhat.com \
--cc=rostedt@goodmis.org \
--cc=snitzer@kernel.org \
--cc=tom@talpey.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox