linux-nfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jeff Layton <jlayton@kernel.org>
To: "J. Bruce Fields" <bfields@fieldses.org>,
	Chuck Lever <chuck.lever@oracle.com>
Cc: linux-nfs@vger.kernel.org, "J. Bruce Fields" <bfields@redhat.com>
Subject: Re: [PATCH 1/5] nfsd: only call inode_query_iversion in the I_VERSION case
Date: Tue, 01 Dec 2020 11:43:31 -0500	[thread overview]
Message-ID: <01bad6aa8aa05bb9bafd010575866125f89c5f08.camel@kernel.org> (raw)
In-Reply-To: <1606776378-22381-1-git-send-email-bfields@fieldses.org>

On Mon, 2020-11-30 at 17:46 -0500, J. Bruce Fields wrote:
> From: "J. Bruce Fields" <bfields@redhat.com>
> 
> inode_query_iversion() can modify i_version.  Depending on the exported
> filesystem, that may not be safe.  For example, if you're re-exporting
> NFS, NFS stores the server's change attribute in i_version and does not
> expect it to be modified locally.  This has been observed causing
> unnecessary cache invalidations.
> 
> The way a filesystem indicates that it's OK to call
> inode_query_iverson() is by setting SB_I_VERSION.
> 
> So, move the I_VERSION check out of encode_change(), where it's used
> only in FATTR responses, to nfsd4_changeattr(), which is also called for
> pre- and post- operation attributes.
> 
> (Note we could also pull the NFSEXP_V4ROOT case into
> nfsd4_change_attribute as well.  That would actually be a no-op, since
> pre/post attrs are only used for metadata-modifying operations, and
> V4ROOT exports are read-only.  But we might make the change in the
> future just for simplicity.)
> 
> Reported-by: Daire Byrne <daire@dneg.com>
> Signed-off-by: J. Bruce Fields <bfields@redhat.com>
> ---
>  fs/nfsd/nfs3xdr.c |  5 ++---
>  fs/nfsd/nfs4xdr.c |  6 +-----
>  fs/nfsd/nfsfh.h   | 14 ++++++++++----
>  3 files changed, 13 insertions(+), 12 deletions(-)
> 
> diff --git a/fs/nfsd/nfs3xdr.c b/fs/nfsd/nfs3xdr.c
> index 2277f83da250..dfbf390ff40c 100644
> --- a/fs/nfsd/nfs3xdr.c
> +++ b/fs/nfsd/nfs3xdr.c
> @@ -291,14 +291,13 @@ void fill_post_wcc(struct svc_fh *fhp)
>  		printk("nfsd: inode locked twice during operation.\n");
>  
> 
> 
> 
>  	err = fh_getattr(fhp, &fhp->fh_post_attr);
> -	fhp->fh_post_change = nfsd4_change_attribute(&fhp->fh_post_attr,
> -						     d_inode(fhp->fh_dentry));
>  	if (err) {
>  		fhp->fh_post_saved = false;
> -		/* Grab the ctime anyway - set_change_info might use it */
>  		fhp->fh_post_attr.ctime = d_inode(fhp->fh_dentry)->i_ctime;
>  	} else
>  		fhp->fh_post_saved = true;
> +	fhp->fh_post_change = nfsd4_change_attribute(&fhp->fh_post_attr,
> +						     d_inode(fhp->fh_dentry));
>  }
>  
> 
> 
> 
>  /*
> diff --git a/fs/nfsd/nfs4xdr.c b/fs/nfsd/nfs4xdr.c
> index 833a2c64dfe8..56fd5f6d5c44 100644
> --- a/fs/nfsd/nfs4xdr.c
> +++ b/fs/nfsd/nfs4xdr.c
> @@ -2298,12 +2298,8 @@ static __be32 *encode_change(__be32 *p, struct kstat *stat, struct inode *inode,
>  	if (exp->ex_flags & NFSEXP_V4ROOT) {
>  		*p++ = cpu_to_be32(convert_to_wallclock(exp->cd->flush_time));
>  		*p++ = 0;
> -	} else if (IS_I_VERSION(inode)) {
> +	} else
>  		p = xdr_encode_hyper(p, nfsd4_change_attribute(stat, inode));
> -	} else {
> -		*p++ = cpu_to_be32(stat->ctime.tv_sec);
> -		*p++ = cpu_to_be32(stat->ctime.tv_nsec);
> -	}
>  	return p;
>  }
>  
> 
> 
> 
> diff --git a/fs/nfsd/nfsfh.h b/fs/nfsd/nfsfh.h
> index 56cfbc361561..39d764b129fa 100644
> --- a/fs/nfsd/nfsfh.h
> +++ b/fs/nfsd/nfsfh.h
> @@ -261,10 +261,16 @@ static inline u64 nfsd4_change_attribute(struct kstat *stat,
>  {
>  	u64 chattr;
>  
> 
> 
> 
> -	chattr =  stat->ctime.tv_sec;
> -	chattr <<= 30;
> -	chattr += stat->ctime.tv_nsec;
> -	chattr += inode_query_iversion(inode);
> +	if (IS_I_VERSION(inode)) {
> +		chattr =  stat->ctime.tv_sec;
> +		chattr <<= 30;
> +		chattr += stat->ctime.tv_nsec;
> +		chattr += inode_query_iversion(inode);
> +	} else {
> +		chattr = stat->ctime.tv_sec;
> +		chattr <<= 32;

Might be nice to annotate the shifts above and maybe make them named
constants. I'm not sure where those values come from, tbh.

> +		chattr += stat->ctime.tv_nsec;
> +	}
>  	return chattr;
>  }
>  
> 
> 
> 


Other than some very minor nits, the set itself looks great.

Are you planning to follow up with the series to add the fetch_iversion
op, or have you decided not to do that for now?

Reviewed-by: Jeff Layton <jlayton@kernel.org>


  parent reply	other threads:[~2020-12-01 16:44 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-30 22:46 [PATCH 1/5] nfsd: only call inode_query_iversion in the I_VERSION case J. Bruce Fields
2020-11-30 22:46 ` [PATCH 2/5] nfsd: simplify nfsd4_change_info J. Bruce Fields
2020-11-30 22:46 ` [PATCH 3/5] nfsd: minor nfsd4_change_attribute cleanup J. Bruce Fields
2020-11-30 22:46 ` [PATCH 4/5] nfsd4: don't query change attribute in v2/v3 case J. Bruce Fields
2020-11-30 22:46 ` [PATCH 5/5] Revert "nfsd4: support change_attr_type attribute" J. Bruce Fields
2020-12-01 16:30 ` [PATCH 1/5] nfsd: only call inode_query_iversion in the I_VERSION case Jeff Layton
2020-12-01 20:12   ` J. Bruce Fields
2020-12-01 16:43 ` Jeff Layton [this message]
2020-12-01 20:38   ` J. Bruce Fields
2020-12-01 21:35   ` J. Bruce Fields
  -- strict thread matches above, loose matches on Subject: below --
2020-11-30 19:38 J. Bruce Fields
2020-11-30 19:46 ` J. Bruce Fields
2020-11-30 21:03 ` Chuck Lever
2020-11-30 21:42   ` Bruce Fields

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=01bad6aa8aa05bb9bafd010575866125f89c5f08.camel@kernel.org \
    --to=jlayton@kernel.org \
    --cc=bfields@fieldses.org \
    --cc=bfields@redhat.com \
    --cc=chuck.lever@oracle.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).