On Fri, 2023-05-19 at 12:36 +0200, Christian Brauner wrote: > 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. I don't have any other big changes queued up. So far, this would just be the exact same set, without this patch. FWIW, I'm mostly interested in your review of patches #1 and 2. Is altering prototype for generic_fillattr, and changing the logic in current_time the right approach here? -- Jeff Layton <jlayton@xxxxxxxxxx>
