linux-nfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Olga Kornievskaia <olga.kornievskaia@gmail.com>
To: "J. Bruce Fields" <bfields@fieldses.org>
Cc: "J. Bruce Fields" <bfields@redhat.com>,
	linux-nfs <linux-nfs@vger.kernel.org>
Subject: Re: [PATCH v4 5/8] NFSD check stateids against copy stateids
Date: Tue, 30 Jul 2019 12:03:38 -0400	[thread overview]
Message-ID: <CAN-5tyFTRr9KPYAzq-EaOMqDeJU31-qHGsLyCmEtd18OMxCFNQ@mail.gmail.com> (raw)
In-Reply-To: <20190723205846.GB19559@fieldses.org>

On Tue, Jul 23, 2019 at 4:59 PM J. Bruce Fields <bfields@fieldses.org> wrote:
>
> On Mon, Jul 22, 2019 at 04:24:08PM -0400, Olga Kornievskaia wrote:
> > On Fri, Jul 19, 2019 at 6:01 PM J. Bruce Fields <bfields@fieldses.org> wrote:
> > >
> > > On Mon, Jul 08, 2019 at 03:23:49PM -0400, Olga Kornievskaia wrote:
> > > > Incoming stateid (used by a READ) could be a saved copy stateid.
> > > > On first use make it active and check that the copy has started
> > > > within the allowable lease time.
> > > >
> > > > Signed-off-by: Olga Kornievskaia <kolga@netapp.com>
> > > > ---
> > > >  fs/nfsd/nfs4state.c | 45 +++++++++++++++++++++++++++++++++++++++++++++
> > > >  1 file changed, 45 insertions(+)
> > > >
> > > > diff --git a/fs/nfsd/nfs4state.c b/fs/nfsd/nfs4state.c
> > > > index 2555eb9..b786625 100644
> > > > --- a/fs/nfsd/nfs4state.c
> > > > +++ b/fs/nfsd/nfs4state.c
> > > > @@ -5232,6 +5232,49 @@ static __be32 nfsd4_validate_stateid(struct nfs4_client *cl, stateid_t *stateid)
> > > >
> > > >       return 0;
> > > >  }
> > > > +/*
> > > > + * A READ from an inter server to server COPY will have a
> > > > + * copy stateid. Return the parent nfs4_stid.
> > > > + */
> > > > +static __be32 _find_cpntf_state(struct nfsd_net *nn, stateid_t *st,
> > > > +                  struct nfs4_cpntf_state **cps)
> > > > +{
> > > > +     struct nfs4_cpntf_state *state = NULL;
> > > > +
> > > > +     if (st->si_opaque.so_clid.cl_id != nn->s2s_cp_cl_id)
> > > > +             return nfserr_bad_stateid;
> > > > +     spin_lock(&nn->s2s_cp_lock);
> > > > +     state = idr_find(&nn->s2s_cp_stateids, st->si_opaque.so_id);
> > > > +     if (state)
> > > > +             refcount_inc(&state->cp_p_stid->sc_count);
> > > > +     spin_unlock(&nn->s2s_cp_lock);
> > > > +     if (!state)
> > > > +             return nfserr_bad_stateid;
> > > > +     *cps = state;
> > > > +     return 0;
> > > > +}
> > > > +
> > > > +static __be32 find_cpntf_state(struct nfsd_net *nn, stateid_t *st,
> > > > +                            struct nfs4_stid **stid)
> > > > +{
> > > > +     __be32 status;
> > > > +     struct nfs4_cpntf_state *cps = NULL;
> > > > +
> > > > +     status = _find_cpntf_state(nn, st, &cps);
> > > > +     if (status)
> > > > +             return status;
> > > > +
> > > > +     /* Did the inter server to server copy start in time? */
> > > > +     if (cps->cp_active == false && !time_after(cps->cp_timeout, jiffies)) {
> > > > +             nfs4_put_stid(cps->cp_p_stid);
> > > > +             return nfserr_partner_no_auth;
> > >
> > > I wonder whether instead of checking the time we should instead be
> > > destroying copy stateid's as they expire, so the fact that you were
> > > still able to look up the stateid suggests that it's good.  Or would
> > > that result in returning the wrong error here?  Just curious.
> >
> > In order to destroy copy stateid as they expire we need some thread
> > monitoring the copies and then remove the expired one.
>
> It would be just another thing to do in the laundromat thread.

This still seems simpler. You'd need to traverse the list and do more
work? What's the advantage of laundry vs this? Given that laundry
thread doesn't run all the time, there might still be a gap with it
was last run and stateid expiring before the next run.

>
> So when do we free these things?  The only free_cpntf_state() caller I
> can find is in nfsd4_offload_cancel,

There is a caller in the nfs4_put_stid. Copy notify state is freed
when the associated stateid going away.

> but I think the client only calls
> those in case of interrupts or other unusual events.  What about a copy
> that terminates normally?

At this point, are you asking about a copy state or a copy_notify
state? When the copy is done, then the destination server will free
the copy state. However, source server doesn't keep track of when the
source server is done with the copy (I don't think we want to do that
to store how much is read and state of the file seems like
unnecessary).

>
> > That seems like
> > a lot more work than what's currently there. The spec says that the
> > use of the copy has to start without a certain timeout and that's what
> > this is suppose to enforce. If the client took too long start the
> > copy, it'll get an error. I don't think it matters what error code is
> > returned BAD_STATEID or PARTNER_NO_AUTH both imply the stateid is bad.
> >
> > >
> > > > +     } else
> > > > +             cps->cp_active = true;
> > > > +
> > > > +     *stid = cps->cp_p_stid;
> > >
> > > What guarantees that cp_p_stid still points to a valid stateid?  (E.g.
> > > if this is an open stateid that has since been closed.)
> >
> > A copy (or copy_notify) stateid takes a reference on the parent, thus
> > we guaranteed that pointer is still a valid stateid.
>
> I only see a reference count taken when one is looked up, in
> find_internal_cpntf_state.  That's too late.

Hm, right so this is tricky. With copy_notify, if I were to take a
reference on the parent when copy_notify is processed, there is no way
to free this reference because the source server never knows when the
copy was done.



>
> --b.
>
> >
> > >
> > > --b.
> > >
> > > > +
> > > > +     return nfs_ok;
> > > > +}
> > > >
> > > >  /*
> > > >   * Checks for stateid operations
> > > > @@ -5264,6 +5307,8 @@ static __be32 nfsd4_validate_stateid(struct nfs4_client *cl, stateid_t *stateid)
> > > >       status = nfsd4_lookup_stateid(cstate, stateid,
> > > >                               NFS4_DELEG_STID|NFS4_OPEN_STID|NFS4_LOCK_STID,
> > > >                               &s, nn);
> > > > +     if (status == nfserr_bad_stateid)
> > > > +             status = find_cpntf_state(nn, stateid, &s);
> > > >       if (status)
> > > >               return status;
> > > >       status = nfsd4_stid_check_stateid_generation(stateid, s,
> > > > --
> > > > 1.8.3.1

  reply	other threads:[~2019-07-30 16:03 UTC|newest]

Thread overview: 51+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-08 19:23 [PATCH v4 0/8] server-side support for "inter" SSC copy Olga Kornievskaia
2019-07-08 19:23 ` [PATCH v4 1/8] NFSD fill-in netloc4 structure Olga Kornievskaia
2019-07-17 21:13   ` J. Bruce Fields
2019-07-22 19:59     ` Olga Kornievskaia
2019-07-30 15:48       ` Olga Kornievskaia
2019-07-30 15:51         ` J. Bruce Fields
2019-07-08 19:23 ` [PATCH v4 2/8] NFSD add ca_source_server<> to COPY Olga Kornievskaia
2019-07-17 21:40   ` J. Bruce Fields
2019-07-22 20:00     ` Olga Kornievskaia
2019-07-08 19:23 ` [PATCH v4 3/8] NFSD return nfs4_stid in nfs4_preprocess_stateid_op Olga Kornievskaia
2019-07-08 19:23 ` [PATCH v4 4/8] NFSD add COPY_NOTIFY operation Olga Kornievskaia
2019-07-09 12:34   ` Anna Schumaker
2019-07-09 15:51     ` Olga Kornievskaia
2019-07-17 22:12   ` J. Bruce Fields
2019-07-17 22:15   ` J. Bruce Fields
2019-07-22 20:03     ` Olga Kornievskaia
2019-07-17 23:07   ` J. Bruce Fields
2019-07-22 20:17     ` Olga Kornievskaia
2019-07-23 20:45       ` J. Bruce Fields
2019-07-30 15:48         ` Olga Kornievskaia
2019-07-30 15:55           ` J. Bruce Fields
2019-07-30 16:13             ` Olga Kornievskaia
2019-07-30 17:10               ` Olga Kornievskaia
2019-07-08 19:23 ` [PATCH v4 5/8] NFSD check stateids against copy stateids Olga Kornievskaia
2019-07-19 22:01   ` J. Bruce Fields
2019-07-22 20:24     ` Olga Kornievskaia
2019-07-23 20:58       ` J. Bruce Fields
2019-07-30 16:03         ` Olga Kornievskaia [this message]
2019-07-31 21:10           ` Olga Kornievskaia
2019-07-31 21:51             ` J. Bruce Fields
2019-08-01 14:12               ` Olga Kornievskaia
2019-08-01 15:12                 ` J. Bruce Fields
2019-08-01 15:41                   ` Olga Kornievskaia
2019-08-01 18:06                     ` Olga Kornievskaia
2019-08-01 18:11                       ` J. Bruce Fields
2019-08-01 18:24                         ` Olga Kornievskaia
2019-08-01 19:36                           ` J. Bruce Fields
2019-08-07 16:02                             ` Olga Kornievskaia
2019-08-07 16:08                               ` J. Bruce Fields
2019-08-07 16:42                                 ` Olga Kornievskaia
2019-08-08 11:25                                   ` J. Bruce Fields
2019-07-08 19:23 ` [PATCH v4 6/8] NFSD generalize nfsd4_compound_state flag names Olga Kornievskaia
2019-07-08 19:23 ` [PATCH v4 7/8] NFSD: allow inter server COPY to have a STALE source server fh Olga Kornievskaia
2019-07-23 21:35   ` J. Bruce Fields
2019-07-30 15:48     ` Olga Kornievskaia
2019-07-08 19:23 ` [PATCH v4 8/8] NFSD add nfs4 inter ssc to nfsd4_copy Olga Kornievskaia
2019-07-09 12:43   ` Anna Schumaker
2019-07-09 15:53     ` Olga Kornievskaia
2019-07-09  3:53 ` [PATCH v4 0/8] server-side support for "inter" SSC copy J. Bruce Fields
2019-07-09 15:47   ` Olga Kornievskaia
2019-07-17 18:05     ` 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=CAN-5tyFTRr9KPYAzq-EaOMqDeJU31-qHGsLyCmEtd18OMxCFNQ@mail.gmail.com \
    --to=olga.kornievskaia@gmail.com \
    --cc=bfields@fieldses.org \
    --cc=bfields@redhat.com \
    --cc=linux-nfs@vger.kernel.org \
    /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;
as well as URLs for NNTP newsgroup(s).