The Linux Kernel Mailing List
 help / color / mirror / Atom feed
From: Jeff Layton <jlayton@kernel.org>
To: Prabhakar Pujeri <prabhakar.pujeri@dell.com>, cel@kernel.org
Cc: neil@brown.name, okorniev@redhat.com, Dai.Ngo@oracle.com,
	tom@talpey.com, 	donald.hunter@gmail.com, kuba@kernel.org,
	linux-nfs@vger.kernel.org, 	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v1 1/3] nfsd: report NFSv4 grace state through Netlink
Date: Tue, 25 Aug 2026 08:10:33 -0400	[thread overview]
Message-ID: <1046756851d9d7d688ac612a7f175e48745d2b84.camel@kernel.org> (raw)
In-Reply-To: <3fd25e2178458fbb44f57f1b0e068c12a6503d17.1787638668.git.prabhakar.pujeri@dell.com>

On Tue, 2026-08-25 at 06:51 +0000, Prabhakar Pujeri wrote:
> Operational tooling needs to distinguish a server that is accepting
> normal NFSv4 state operations from one that is still accepting only
> recovery requests. The existing Netlink threads query reports
> server-wide configuration, but recovery state is available only through
> the nfsd filesystem.
> 
> Add an in-grace value to the threads-get reply. Return it in every reply
> so user space can distinguish a server that is not in grace from an older
> kernel that does not provide the attribute.
> 
> Signed-off-by: Prabhakar Pujeri <prabhakar.pujeri@dell.com>
> ---
>  Documentation/admin-guide/nfs/nfsd-admin-interfaces.rst | 3 +++
>  Documentation/netlink/specs/nfsd.yaml                   | 6 ++++++
>  fs/nfsd/nfsctl.c                                        | 9 ++++++++-
>  include/uapi/linux/nfsd_netlink.h                       | 1 +
>  4 files changed, 18 insertions(+), 1 deletion(-)
> 
> diff --git a/Documentation/admin-guide/nfs/nfsd-admin-interfaces.rst b/Documentation/admin-guide/nfs/nfsd-admin-interfaces.rst
> index c05926f79054..35c174000ab3 100644
> --- a/Documentation/admin-guide/nfs/nfsd-admin-interfaces.rst
> +++ b/Documentation/admin-guide/nfs/nfsd-admin-interfaces.rst
> @@ -25,6 +25,9 @@ udp and one tcp listener at port 2049 (see nfsd_init_socks).
>  On startup, nfsd and lockd grace periods start. nfsd is shut down by a write of
>  0 to nfsd/threads.  All locks and state are thrown away at that point.
>  
> +The ``in-grace`` value in the ``threads-get`` Generic Netlink reply reports
> +whether the NFSv4 server's recovery grace period is still active.
> +
>  Between startup and shutdown, the number of threads may be adjusted up
>  or down by additional writes to nfsd/threads or by writes to
>  nfsd/pool_threads.
> diff --git a/Documentation/netlink/specs/nfsd.yaml b/Documentation/netlink/specs/nfsd.yaml
> index 642268819c6f..d01d93f39392 100644
> --- a/Documentation/netlink/specs/nfsd.yaml
> +++ b/Documentation/netlink/specs/nfsd.yaml
> @@ -130,6 +130,11 @@ attribute-sets:
>          type: binary
>          checks:
>              exact-len: 16
> +      -
> +        name: in-grace
> +        type: u8
> +        doc: One while the NFSv4 server is in its recovery grace period,
> +             otherwise zero.
>    -
>      name: version
>      attributes:
> @@ -464,6 +469,7 @@ operations:
>              - leasetime
>              - scope
>              - min-threads
> +            - in-grace
>      -
>        name: version-set
>        doc: set nfs enabled versions
> diff --git a/fs/nfsd/nfsctl.c b/fs/nfsd/nfsctl.c
> index 6e63950a99e1..7ea865b372cc 100644
> --- a/fs/nfsd/nfsctl.c
> +++ b/fs/nfsd/nfsctl.c
> @@ -1775,6 +1775,7 @@ int nfsd_nl_threads_get_doit(struct sk_buff *skb, struct genl_info *info)
>  {
>  	struct net *net = genl_info_net(info);
>  	struct nfsd_net *nn = net_generic(net, nfsd_net_id);
> +	bool in_grace = false;
>  	void *hdr;
>  	int err;
>  
> @@ -1790,6 +1791,11 @@ int nfsd_nl_threads_get_doit(struct sk_buff *skb, struct genl_info *info)
>  
>  	mutex_lock(&nfsd_mutex);
>  
> +#ifdef CONFIG_NFSD_V4
> +	in_grace = nfsd_vers(nn, 4, NFSD_TEST) &&
> +		test_bit(NFSD_NET_UP, &nn->flags) &&
> +		!test_bit(NFSD_NET_GRACE_ENDED, &nn->flags);
> +#endif


What's your interest in reporting this info?

Just because the v4 recovery is done does not mean that you will be
able to access files. The overall system grace period is a union of
both the NLM and v4 grace periods.

This patch is reporting just the v4 one. If the goal is for the admin
to reliably tell when the grace period has been lifted, then this won't
tell us that.

Maybe this should just return the result of locks_in_grace() instead?

Or, do you plan to add similar functionality to lockd? Then you can
just do the union in userland to figure out if it has been lifted.

>  	err = nla_put_u32(skb, NFSD_A_SERVER_GRACETIME,
>  			  nn->nfsd4_grace) ||
>  	      nla_put_u32(skb, NFSD_A_SERVER_LEASETIME,
> @@ -1797,7 +1803,8 @@ int nfsd_nl_threads_get_doit(struct sk_buff *skb, struct genl_info *info)
>  	      nla_put_u32(skb, NFSD_A_SERVER_MIN_THREADS,
>  			  nn->min_threads) ||
>  	      nla_put_string(skb, NFSD_A_SERVER_SCOPE,
> -			  nn->nfsd_name);
> +			  nn->nfsd_name) ||
> +	      nla_put_u8(skb, NFSD_A_SERVER_IN_GRACE, in_grace);
>  	if (err)
>  		goto err_unlock;
>  
> diff --git a/include/uapi/linux/nfsd_netlink.h b/include/uapi/linux/nfsd_netlink.h
> index 87da1d0bb21e..e1fc2db00046 100644
> --- a/include/uapi/linux/nfsd_netlink.h
> +++ b/include/uapi/linux/nfsd_netlink.h
> @@ -84,6 +84,7 @@ enum {
>  	NFSD_A_SERVER_SCOPE,
>  	NFSD_A_SERVER_MIN_THREADS,
>  	NFSD_A_SERVER_FH_KEY,
> +	NFSD_A_SERVER_IN_GRACE,
>  
>  	__NFSD_A_SERVER_MAX,
>  	NFSD_A_SERVER_MAX = (__NFSD_A_SERVER_MAX - 1)

-- 
Jeff Layton <jlayton@kernel.org>

  reply	other threads:[~2026-08-25 12:10 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-25  6:51 [PATCH v1 0/3] nfsd: expose NFSv4 client state through Netlink Prabhakar Pujeri
2026-08-25  6:51 ` [PATCH v1 1/3] nfsd: report NFSv4 grace " Prabhakar Pujeri
2026-08-25 12:10   ` Jeff Layton [this message]
2026-08-25  6:51 ` [PATCH v1 2/3] nfsd: add a Netlink dump of NFSv4 clients Prabhakar Pujeri
2026-08-25  6:51 ` [PATCH v1 3/3] nfsd: report per-client NFSv4 state usage through Netlink Prabhakar Pujeri

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=1046756851d9d7d688ac612a7f175e48745d2b84.camel@kernel.org \
    --to=jlayton@kernel.org \
    --cc=Dai.Ngo@oracle.com \
    --cc=cel@kernel.org \
    --cc=donald.hunter@gmail.com \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-nfs@vger.kernel.org \
    --cc=neil@brown.name \
    --cc=okorniev@redhat.com \
    --cc=prabhakar.pujeri@dell.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