Received: by 2002:a25:ad19:0:0:0:0:0 with SMTP id y25csp4210913ybi; Fri, 19 Jul 2019 17:37:29 -0700 (PDT) X-Google-Smtp-Source: APXvYqy9B3YfbHKkY0/EiP8F/yYV1lwCa462FZo/FF4sSgNQIw3RP9Lt+3NUEa6yDyY4hV9p3dSs X-Received: by 2002:a65:5c4b:: with SMTP id v11mr13976882pgr.62.1563583048909; Fri, 19 Jul 2019 17:37:28 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1563583048; cv=none; d=google.com; s=arc-20160816; b=BAgLPpNwZoytlnEuDwlp4XGSuhqoq9RoAp7iOVucjbttmIvrs3IxdGJn9j7e8utbz6 zP47kkVEQDqc6XvNtvPrDH7PfndDBFcz2sCNzL3tv19/pqH9HRWXK/yTPat6CXi6fj9e qoIQX86ajJiMxm03zkaUVc72PKjU3hOHcPGoUCp+TVIVp6cgnnOrk3GvdAGyRU1uDWyc 6r8qly3+1QYGbN6ft66Mgtiu4eZNzeLbgdOO3GF4bClnb1UYIbjuQIhK1PchcT0qhpb9 YuvXgqS7ZF3I/5OglURTh50hWDuaA28s9WikrpLHsU2LB0yvVBBNJxGiyE/yGqXvuB+G 47mQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:from:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:date; bh=apUIJ98QcbrZyaE2LElDvr80YAoFa7Vc2sO5tRRVQMM=; b=tT8rXPwgUisqoaVTaCJTN5LdjSoCuZhTSbZzJhcwxH4oiBBwL3RNjouGNGbR1ql2Yv 41seJ8GbvoHtee8IXkZJFeuvtiVns+EU+nvKEIVP2NXB5yrFBtx7LWzUPZ5RLXoC4SRK rAKgo5gIdm8yqWM4pJ9jrLWj1ftmISsYydjTR7COwJ+5RtDR/Lz6pUDhhIXAvj5A3ZWB TTWle1KzT8ZywAiBTtqvUFpOt6wVr2XgoBOn7uRxdot93N9rWNI7KUNtgdS1PmPbSlhq Waf7Gd43X2WpWNIncCRSqICrp885wJqQDfmrf7FgHlYBsrHRjQI2xUyDafLJsZzuh2AN ifEQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-nfs-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-nfs-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id v4si1522090plp.212.2019.07.19.17.37.03; Fri, 19 Jul 2019 17:37:28 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-nfs-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-nfs-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-nfs-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727734AbfGSWBQ (ORCPT + 99 others); Fri, 19 Jul 2019 18:01:16 -0400 Received: from fieldses.org ([173.255.197.46]:58670 "EHLO fieldses.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727344AbfGSWBQ (ORCPT ); Fri, 19 Jul 2019 18:01:16 -0400 Received: by fieldses.org (Postfix, from userid 2815) id 6B29A1D39; Fri, 19 Jul 2019 18:01:16 -0400 (EDT) Date: Fri, 19 Jul 2019 18:01:16 -0400 To: Olga Kornievskaia Cc: bfields@redhat.com, linux-nfs@vger.kernel.org Subject: Re: [PATCH v4 5/8] NFSD check stateids against copy stateids Message-ID: <20190719220116.GA24373@fieldses.org> References: <20190708192352.12614-1-olga.kornievskaia@gmail.com> <20190708192352.12614-6-olga.kornievskaia@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190708192352.12614-6-olga.kornievskaia@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) From: bfields@fieldses.org (J. Bruce Fields) Sender: linux-nfs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-nfs@vger.kernel.org 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 > --- > 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. > + } 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.) --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