On Tue, Jul 02, 2024 at 08:21:42AM GMT, Jeff Layton wrote: > On Tue, 2024-07-02 at 05:15 -0700, Christoph Hellwig wrote: > > 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. > > > > Many of the existing callers of inode_ctime_to_ts are in void return > functions. They're just copying data from an internal representation to > struct inode and assume it always succeeds. For those we'll probably > have to catch bad ctime values earlier. > > So, I think I'll probably have to roll bespoke error handling in all of > the relevant filesystems if we go this route. There are also Shudder, let's try and avoid that.
