On Mon, 18 Sept 2023 at 13:56, Jeff Layton <jlayton@xxxxxxxxxx> wrote:
>
> We may have a problem with the ctime update though, since you pointed it
> out. We have this in inode_set_ctime_current(), in the codepath where
> the QUERIED bit isn't set:
>
> /*
> * If we've recently updated with a fine-grained timestamp,
> * then the coarse-grained one may still be earlier than the
> * existing ctime. Just keep the existing value if so.
> */
> ctime.tv_sec = inode->__i_ctime.tv_sec;
> if (timespec64_compare(&ctime, &now) > 0)
> return ctime;
>
> The ctime can't be set via utimes(), so that's not an issue here, but we
> could get a realtime clock jump backward that causes this to not be
> updated like it should be.
>
> I think (like you suggest above) that this needs some bounds-checking
> where we make sure that the current coarse grained time isn't more than
> around 1-2 jiffies earlier than the existing ctime. If it is, then we'll
> go ahead and just update it anyway.
>
> Thoughts?
Ack, that sounds about right to me.
Christian - I'm just going to assume that you'll sort this out and
I'll get a new pull request at some point. Holler if you think
something else is needed, ok?
Linus
