Re: [RFC PATCH 2/2] lockd: while grace prefer to fail with nlm_lck_denied_grace_period

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Aug 11, 2025 at 3:42 PM Jeff Layton <jlayton@xxxxxxxxxx> wrote:
>
> On Mon, 2025-08-11 at 14:18 -0400, Olga Kornievskaia wrote:
> > When nfsd is in grace and receives an NLM LOCK request which turns
> > out to have a conflicting delegation, return that the server is in
> > grace.
> >
> > Signed-off-by: Olga Kornievskaia <okorniev@xxxxxxxxxx>
> > ---
> >  fs/lockd/svc4proc.c | 15 +++++++++++++--
> >  1 file changed, 13 insertions(+), 2 deletions(-)
> >
> > diff --git a/fs/lockd/svc4proc.c b/fs/lockd/svc4proc.c
> > index 109e5caae8c7..7ac4af5c9875 100644
> > --- a/fs/lockd/svc4proc.c
> > +++ b/fs/lockd/svc4proc.c
> > @@ -141,8 +141,19 @@ __nlm4svc_proc_lock(struct svc_rqst *rqstp, struct nlm_res *resp)
> >       resp->cookie = argp->cookie;
> >
> >       /* Obtain client and file */
> > -     if ((resp->status = nlm4svc_retrieve_args(rqstp, argp, &host, &file)))
> > -             return resp->status == nlm_drop_reply ? rpc_drop_reply :rpc_success;
> > +     resp->status = nlm4svc_retrieve_args(rqstp, argp, &host, &file);
> > +     switch (resp->status) {
> > +     case 0:
> > +             break;
> > +     case nlm_drop_reply:
> > +             if (locks_in_grace(SVC_NET(rqstp))) {
> > +                     resp->status = nlm_lck_denied_grace_period;
> > +                     return rpc_success;
> > +             }
> > +             return nlm_drop_reply;
> > +     default:
> > +             return rpc_success;
> > +     }
> >
> >       /* Now try to lock the file */
> >       resp->status = nlmsvc_lock(rqstp, file, host, &argp->lock,
>
> ACK to returning the right error code in this case, but you may want to
> do this differently if you agree with me on patch #1.

I'm not sure what is the suggestion from the patch#1. Unless the
suggestion is for the server to return "denied" and then also for the
client to implement handling that error by retrying? So I wonder how
would that go? Should the client retry indefinitely or how long should
be waiting to retry the request instead of failing...

And also I'm somewhat uncomfortable in changing the client's
interpretation of the NLM's "denied" error code.


> --
> Jeff Layton <jlayton@xxxxxxxxxx>
>





[Index of Archives]     [Linux Filesystem Development]     [Linux USB Development]     [Linux Media Development]     [Video for Linux]     [Linux NILFS]     [Linux Audio Users]     [Yosemite Info]     [Linux SCSI]

  Powered by Linux