On Tue, Jul 02, 2024 at 08:09:46AM -0400, Jeff Layton wrote:
quoted
quoted
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.
quoted
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.