On Tue, Jul 02, 2024 at 08:09:46AM -0400, Jeff Layton wrote: > > > corrupt timestamps like this? > > > > inode_set_ctime_to_ts should return an error if things are out of range. > > Currently it just returns the timespec64 we're setting it to (which > makes it easy to do several assignments), so we'd need to change its > prototype to handle this case, and fix up the callers to recognize the > error. > > Alternately it may be easier to just add in a test for when > __i_ctime == KTIME_MAX in the appropriate callers and have them error > out. I'll have a look and see what makes sense. The seems like a more awkward interface vs one that explicitly checks. > > > How do we currently catch this when it comes from userland? > > > > Not sure I understand this question. ctime values should never come > from userland. They should only ever come from the system clock. Ah, yes, utimes only changes mtime.
