From: Trond Myklebust <trondmy@kernel.org>
To: Olga Kornievskaia <aglo@umich.edu>,
Olga Kornievskaia <okorniev@redhat.com>
Cc: anna.schumaker@oracle.com, linux-nfs@vger.kernel.org
Subject: Re: [PATCH 1/1] NFSv4: handle ERR_GRACE on delegation recalls
Date: Fri, 12 Sep 2025 10:29:09 -0400 [thread overview]
Message-ID: <2b87402379d4c88545dabce30d2877722940f483.camel@kernel.org> (raw)
In-Reply-To: <CAN-5tyEmf9HHMuXHDU86Y5FWYZz+ZYFKctmoLaCAB+DZ1zcXSQ@mail.gmail.com>
On Fri, 2025-09-12 at 10:21 -0400, Olga Kornievskaia wrote:
> Any comments on or objections to this patch? It does lead to possible
> data corruption.
>
Sorry, I think was travelling when you originally sent this patch.
> On Mon, Aug 11, 2025 at 2:25 PM Olga Kornievskaia
> <okorniev@redhat.com> wrote:
> >
> > RFC7530 states that clients should be prepared for the return of
> > NFS4ERR_GRACE errors for non-reclaim lock and I/O requests.
> >
> > Signed-off-by: Olga Kornievskaia <okorniev@redhat.com>
> > ---
> > fs/nfs/nfs4proc.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/fs/nfs/nfs4proc.c b/fs/nfs/nfs4proc.c
> > index 341740fa293d..fa9b81300604 100644
> > --- a/fs/nfs/nfs4proc.c
> > +++ b/fs/nfs/nfs4proc.c
> > @@ -7867,10 +7867,10 @@ int nfs4_lock_delegation_recall(struct
> > file_lock *fl, struct nfs4_state *state,
> > return err;
> > do {
> > err = _nfs4_do_setlk(state, F_SETLK, fl,
> > NFS_LOCK_NEW);
> > - if (err != -NFS4ERR_DELAY)
> > + if (err != -NFS4ERR_DELAY && err != -NFS4ERR_GRACE)
> > break;
> > ssleep(1);
> > - } while (err == -NFS4ERR_DELAY);
> > + } while (err == -NFS4ERR_DELAY || err == -NFSERR_GRACE);
> > return nfs4_handle_delegation_recall_error(server, state,
> > stateid, fl, err);
> > }
> >
> > --
> > 2.47.1
> >
> >
Should the server be sending NFS4ERR_GRACE in this case, though? The
client already holds a delegation, so it is clear that other clients
cannot reclaim any locks that would conflict.
..or is the issue that this could happen before the client has a chance
to reclaim the delegation after a reboot?
--
Trond Myklebust
Linux NFS client maintainer, Hammerspace
trondmy@kernel.org, trond.myklebust@hammerspace.com
next prev parent reply other threads:[~2025-09-12 14:29 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-11 18:18 [PATCH 1/1] NFSv4: handle ERR_GRACE on delegation recalls Olga Kornievskaia
2025-09-12 14:21 ` Olga Kornievskaia
2025-09-12 14:29 ` Trond Myklebust [this message]
2025-09-12 14:41 ` Olga Kornievskaia
2025-09-12 15:11 ` Trond Myklebust
2025-09-12 16:04 ` Olga Kornievskaia
2025-09-29 17:49 ` Olga Kornievskaia
2025-09-30 14:01 ` Chuck Lever
2025-09-30 14:29 ` Olga Kornievskaia
2025-09-30 14:32 ` Olga Kornievskaia
2025-09-30 14:37 ` Chuck Lever
2025-09-30 14:56 ` Olga Kornievskaia
2025-09-30 15:19 ` Chuck Lever
2025-09-30 17:00 ` Olga Kornievskaia
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=2b87402379d4c88545dabce30d2877722940f483.camel@kernel.org \
--to=trondmy@kernel.org \
--cc=aglo@umich.edu \
--cc=anna.schumaker@oracle.com \
--cc=linux-nfs@vger.kernel.org \
--cc=okorniev@redhat.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 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.