On Tue, 25 Jul 2023, Jeff Layton wrote: > In the event that we can't fetch post_op_attr attributes, we still need > to set a value for the after_change. The operation has already happened, > so we're not able to return an error at that point, but we do want to > ensure that the client knows that its cache should be invalidated. > > If we weren't able to fetch post-op attrs, then just set the > after_change to before_change + 1. The atomic flag should already be > clear in this case. > > Suggested-by: Neil Brown <neilb@xxxxxxx> > Signed-off-by: Jeff Layton <jlayton@xxxxxxxxxx> > --- > fs/nfsd/nfs4proc.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/fs/nfsd/nfs4proc.c b/fs/nfsd/nfs4proc.c > index 3f6710c9c5c9..f0f318e78630 100644 > --- a/fs/nfsd/nfs4proc.c > +++ b/fs/nfsd/nfs4proc.c > @@ -411,7 +411,7 @@ set_change_info(struct nfsd4_change_info *cinfo, struct svc_fh *fhp) > if (WARN_ON_ONCE(!fhp->fh_pre_saved)) > cinfo->before_change = 0; > if (!fhp->fh_post_saved) > - cinfo->after_change = 0; > + cinfo->after_change = cinfo->before_change + 1; > } Thanks for this Jeff. Only problem is that the comment above this code is now even more wrong than it was before :-) I cannot convincingly argue that having the "+1" is better than not (as Chuck wondered about), but I think "0" is completely arbitrary, while ->before_change+1 is the sort of value we might reasonably expect. Thanks, NeilBrown > > static __be32 > > --- > base-commit: 97a5d0146ef443df148805a4e9c3c44111f14ab1 > change-id: 20230724-bz2223560-5ed6bc3a5db7 > > Best regards, > -- > Jeff Layton <jlayton@xxxxxxxxxx> > >
