On Tue, Jul 02, 2024 at 07:44:19AM -0400, Jeff Layton wrote: > Complaining about it is fairly simple. We could just throw a pr_warn in > inode_set_ctime_to_ts when the time comes back as KTIME_MAX. This might > also be what we need to do for filesystems like NFS, where a future > ctime on the server is not necessarily a problem for the client. > > Refusing to load the inode on disk-based filesystems is harder, but is > probably possible. There are ~90 calls to inode_set_ctime_to_ts in the > kernel, so we'd need to vet the places that are loading times from disk > images or the like and fix them to return errors in this situation. > > Is warning acceptable, or do we really need to reject inodes that have > corrupt timestamps like this? inode_set_ctime_to_ts should return an error if things are out of range. How do we currently catch this when it comes from userland?
