All of lore.kernel.org
 help / color / mirror / Atom feed
From: NeilBrown <neilb@suse.com>
To: Trond Myklebust <trond.myklebust@primarydata.com>
Cc: Linux NFS Mailing List <linux-nfs@vger.kernel.org>
Subject: Re: [PATCH/RFC] NFSv4 - do not accept an incompatible delegation.
Date: Mon, 29 Jun 2015 14:24:06 +1000	[thread overview]
Message-ID: <20150629142406.0afdd862@noble> (raw)
In-Reply-To: <CAHQdGtTWszzRdN+akenDkbiXd7xAJwAr6=144m6+dPWSxZ=boA@mail.gmail.com>

On Mon, 22 Jun 2015 21:16:37 -0400 Trond Myklebust
<trond.myklebust@primarydata.com> wrote:

> On Mon, Jun 22, 2015 at 9:07 PM, NeilBrown <neilb@suse.com> wrote:

> > So maybe something like this:
> >
> > diff --git a/fs/nfs/nfs4proc.c b/fs/nfs/nfs4proc.c
> > index 55e1e3a..ce5f1489 100644
> > --- a/fs/nfs/nfs4proc.c
> > +++ b/fs/nfs/nfs4proc.c
> > @@ -1553,6 +1553,10 @@ static int nfs4_open_recover_helper(struct nfs4_opendata *opendata, fmode_t fmod
> >         struct nfs4_state *newstate;
> >         int ret;
> >
> > +       if ((opendata->o_arg.claim == NFS4_OPEN_CLAIM_DELEGATE_CUR ||
> > +            opendata->o-arg.claim == NFS4_OPEN_CLAIM_DELE_CUR_FH) &&
> > +           (opendata->o_arg.u_delegation_type & mode) != mode)
> > +               return 0;
> >         opendata->o_arg.open_flags = 0;
> >         opendata->o_arg.fmode = fmode;
> >         opendata->o_arg.share_access = nfs4_map_atomic_open_share(
> >
> >
> > I'm not entirely clear on the process of reclaiming opens and
> > delegations after a server reboot, so this may need to be adjusted to
> > handle that correctly.
> 
> The above is along the lines of what I was suggesting. I hope it tests out OK.
> 

Once I fixed the syntax errors, this was all I needed.
I was concerned there might be similar issues with
OPEN_CLAIM_DELEGATE_PREV (or whatever it is called) but Linux doesn't
appear to use that.

I tested it by commenting out

	status = vfs_setlease(filp, fl->fl_type, &fl, NULL);

in nfs4_setlease in the Linux nfsd, so that it would always return a
read delegation.  This was enough to demonstrate the problem and verify
the fix.
I haven't yet received confirmation from people with access to the
Netapp but I would be very surprised if this doesn't work (though I
think there are other issues that still need to be examined).

Separately I've discovered a bug that causes a livelock when a TCP
sendmsg fails because kmalloc failed.  I'll send patches for both.

NeilBrown

      reply	other threads:[~2015-06-29  4:24 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-06-22  7:53 [PATCH/RFC] NFSv4 - do not accept an incompatible delegation NeilBrown
2015-06-22 11:41 ` Trond Myklebust
2015-06-22 21:04   ` NeilBrown
2015-06-22 21:34     ` Trond Myklebust
2015-06-23  1:07       ` NeilBrown
2015-06-23  1:16         ` Trond Myklebust
2015-06-29  4:24           ` NeilBrown [this message]

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=20150629142406.0afdd862@noble \
    --to=neilb@suse.com \
    --cc=linux-nfs@vger.kernel.org \
    --cc=trond.myklebust@primarydata.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.