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?