All of lore.kernel.org
 help / color / mirror / Atom feed
From: bfields@fieldses.org (J. Bruce Fields)
To: Olga Kornievskaia <olga.kornievskaia@gmail.com>
Cc: "J. Bruce Fields" <bfields@redhat.com>,
	linux-nfs <linux-nfs@vger.kernel.org>
Subject: Re: [PATCH v5 5/9] NFSD add COPY_NOTIFY operation
Date: Fri, 30 Aug 2019 13:56:08 -0400	[thread overview]
Message-ID: <20190830175608.GA5053@fieldses.org> (raw)
In-Reply-To: <CAN-5tyHOr+0WVthzu6G9qOwaVG0R+yUpuh2iyaTpBkw_O5XGAA@mail.gmail.com>

On Thu, Aug 29, 2019 at 03:23:43PM -0400, Olga Kornievskaia wrote:
> I'm stuck again. The idea that Trond gave me is to instead of storing
> the pointer to the stateid, (copy) store the stateid_t structure
> itself and then use it to look it up the appropriate nfs4_stid.
> 
> The problem with that is when nfsd4_lookup_stateid() is called it
> takes is a compound state (cstate) which has a client pointer and
> during the lookup it's verified that the client looking up the stateid
> is the same that generate the stateid which is not the case with copy
> offload.
> 
> I tried also saving a cl_clientid and using that to lookup the
> nfs4_client that's needed for the stateid lookup but I'm not sure
> that's possible. lookup_clientid() calls find_client_in_id_table() and
> always passes "false" for sessions args. Original client has minor
> version 2 and then the check if (clp->minor_versions != sessions)
> fails. I don't understand what this logic is suppose to check.
> 
> Should I be writing special version of the lookup_clientid that
> ignores that check (when called in the path of the copy_notify
> verification)? Or any other ideas of how to get passed this would be
> appreciated it.

Yeah, I think you may want to do the clientid lookup by hand under
cl_lock, and take the cl_ref?

Or turn things around and ensure that copy stateid's are destroyed
before clients are.

--b.

  reply	other threads:[~2019-08-30 17:56 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-08 20:18 [PATCH v5 0/9] server-side support for "inter" SSC copy Olga Kornievskaia
2019-08-08 20:18 ` [PATCH v5 1/9] NFSD fill-in netloc4 structure Olga Kornievskaia
2019-08-11  5:48   ` kbuild test robot
2019-08-12 16:12     ` Olga Kornievskaia
2019-08-12 19:58       ` J. Bruce Fields
2019-08-08 20:18 ` [PATCH v5 2/9] NFSD add ca_source_server<> to COPY Olga Kornievskaia
2019-08-11  5:59   ` kbuild test robot
2019-08-11  7:00   ` kbuild test robot
2019-08-08 20:18 ` [PATCH v5 3/9] NFSD return nfs4_stid in nfs4_preprocess_stateid_op Olga Kornievskaia
2019-08-08 20:18 ` [PATCH v5 4/9] NFSD COPY_NOTIFY xdr Olga Kornievskaia
2019-08-11  6:10   ` kbuild test robot
2019-08-08 20:18 ` [PATCH v5 5/9] NFSD add COPY_NOTIFY operation Olga Kornievskaia
2019-08-11  6:17   ` kbuild test robot
2019-08-12 16:19   ` Olga Kornievskaia
2019-08-12 19:16     ` Olga Kornievskaia
2019-08-12 20:00       ` J. Bruce Fields
2019-08-12 20:00         ` J. Bruce Fields
2019-08-13 17:57         ` Olga Kornievskaia
2019-08-14 15:05           ` Olga Kornievskaia
2019-08-29 19:23             ` Olga Kornievskaia
2019-08-30 17:56               ` J. Bruce Fields [this message]
2019-08-08 20:18 ` [PATCH v5 6/9] NFSD check stateids against copy stateids Olga Kornievskaia
2019-08-08 20:18 ` [PATCH v5 7/9] NFSD generalize nfsd4_compound_state flag names Olga Kornievskaia
2019-08-08 20:18 ` [PATCH v5 8/9] NFSD: allow inter server COPY to have a STALE source server fh Olga Kornievskaia
2019-08-08 20:18 ` [PATCH v5 9/9] NFSD add nfs4 inter ssc to nfsd4_copy Olga Kornievskaia
2019-08-11  6:24   ` kbuild test robot
2019-09-04 20:50 ` [PATCH v5 0/9] server-side support for "inter" SSC copy J. Bruce Fields
2019-09-05  0:05   ` Olga Kornievskaia
2019-09-05  0:13     ` Rick Macklem
2019-09-06 14:23       ` Olga Kornievskaia
2019-09-06 15:32         ` Rick Macklem

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=20190830175608.GA5053@fieldses.org \
    --to=bfields@fieldses.org \
    --cc=bfields@redhat.com \
    --cc=linux-nfs@vger.kernel.org \
    --cc=olga.kornievskaia@gmail.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.