Re: [PATCH v4 4/9] nfsd: ensure we use ctime_peek to grab the inode->i_ctime

[Christian Brauner]

On Thu, May 18, 2023 at 11:31:45AM -0400, Jeff Layton wrote:
> On Thu, 2023-05-18 at 13:43 +0000, Chuck Lever III wrote:
> > 
> > > On May 18, 2023, at 7:47 AM, Jeff Layton <jlayton@xxxxxxxxxx> wrote:
> > > 
> > > If getattr fails, then nfsd can end up scraping the time values directly
> > > out of the inode for pre and post-op attrs. This may or may not be the
> > > right thing to do, but for now make it at least use ctime_peek in this
> > > situation to ensure that the QUERIED flag is masked.
> > 
> > That code comes from:
> > 
> > commit 39ca1bf624b6b82cc895b0217889eaaf572a7913
> > Author:     Amir Goldstein <amir73il@xxxxxxxxx>
> > AuthorDate: Wed Jan 3 17:14:35 2018 +0200
> > Commit:     J. Bruce Fields <bfields@xxxxxxxxxx>
> > CommitDate: Thu Feb 8 13:40:17 2018 -0500
> > 
> >     nfsd: store stat times in fill_pre_wcc() instead of inode times
> > 
> >     The time values in stat and inode may differ for overlayfs and stat time
> >     values are the correct ones to use. This is also consistent with the fact
> >     that fill_post_wcc() also stores stat time values.
> > 
> >     This means introducing a stat call that could fail, where previously we
> >     were just copying values out of the inode.  To be conservative about
> >     changing behavior, we fall back to copying values out of the inode in
> >     the error case.  It might be better just to clear fh_pre_saved (though
> >     note the BUG_ON in set_change_info).
> > 
> >     Signed-off-by: Amir Goldstein <amir73il@xxxxxxxxx>
> >     Signed-off-by: J. Bruce Fields <bfields@xxxxxxxxxx>
> > 
> > I was thinking it might have been added to handle odd corner
> > cases around re-exporting NFS mounts, but that does not seem
> > to be the case.
> > 
> > The fh_getattr() can fail for legitimate reasons -- like the
> > file is in the middle of being deleted or renamed over -- I
> > would think. This code should really deal with that by not
> > adding pre-op attrs, since they are optional.
> > 
> 
> That sounds fine to me. I'll plan to drop this patch from the series and
> I'll send a separate patch to just remove those branches altogether
> (which should DTRT).

I'll wait with reviewing this until you send the next version then.