Re: [PATCH v1 1/3] nfsd: report NFSv4 grace state through Netlink

[Prabhakar Pujeri]

On Tue, 2026-08-25 at 08:10 -0400, Jeff Layton wrote:
> What's your interest in reporting this info?

My interest is in making nfsd's operational state observable to
monitoring and validation tooling without parsing nfsdfs.

Concretely, I'm building a validation harness for NFS server
restart and failover behaviour: bounce the server, drive reclaim from a
set of clients, and check that state comes back the way it should. That
kind of test has to know when the grace period has actually lifted
before it can move on to the next phase. Polling
/proc/fs/nfsd/v4_end_grace works, but it is a text interface, it only
answers for nfsd's v4 lock manager, and new nfsd control and
observability interfaces are going to the netlink family instead.

So I would rather frame this as parity than as new information: grace
state is already exported, this puts it on the interface that is
replacing the one exporting it, and -- per your point below -- fixes
the semantics on the way over.

> 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.

Agreed, and "has the grace period lifted" is the question I actually
care about. I mirrored the semantics of /proc/fs/nfsd/v4_end_grace
without stopping to ask whether those were the useful semantics to
expose in a new interface. They aren't.

> 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.

I don't think lockd needs to grow anything -- fs/nfs_common/grace.c
already gives us both halves, and nfsd calls into both helpers today:

  - locks_in_grace() is the union you describe: true while any lock
    manager in the net ns is still in grace.

  - opens_in_grace() is true only while a manager with ->block_opens
    is in grace, which per the comment on struct lock_manager is the
    NFSv4-and-up case; NLM doesn't set it.

So for v2 I'll report locks_in_grace(), which answers "can this server
hand out normal locks and opens yet" rather than "is nfsd's v4 lock
manager done". If it's ever worth distinguishing the two, a second
attribute carrying opens_in_grace() gets there without touching lockd,
and userland can derive the NLM-only case as (locks && !opens). I'd
rather not add that speculatively, but say the word if you'd like both
in v2.

Two things fall out of the switch, both improvements:

  - The #ifdef CONFIG_NFSD_V4 and the open-coded
    nfsd_vers()/NFSD_NET_UP/NFSD_NET_GRACE_ENDED test all go away.
    NFSD selects LOCKD which selects GRACE_PERIOD, so the helper is
    always available, and a lock manager that isn't running simply
    isn't on the grace list.

  - It stops being a v4-specific answer that just happens to be served
    out of the nfsd netlink family.

I'll rename the attribute and fix the yaml and rst wording so the
union semantics are explicit rather than implied.

One design question while I'm respinning. threads-get otherwise
reports configuration, and this is dynamic state, so grace could
equally live in its own operation. My inclination is to keep just this
boolean on threads-get for now, since that is the direct nfsdfs
parity, and to grow any richer grace/recovery detail -- elapsed time,
expected vs completed reclaims, whether grace was extended or
force-ended -- as a separate operation later rather than widening
threads-get. But if you'd rather grace not ride on threads-get at all
and start that separate op now, I'm glad to go that way instead.

Thanks for the review.

--
Prabhakar