On Mon, 27 Feb 2017, Arnd Bergmann wrote:
Good idea, thanks! We currently do the checking separately from the copying, but doing the two together is a good cleanup and also helps the places that currently lack a range check (typically in drivers). We have three different checks on a timespec at the moment (no check on tv_sec range, tv_sec must be positive, or tv_sec must be within the 400 year range of 64-bit nanoseconds), but the check for the nanoseconds is always the same.
I'd expect two different versions of the nanoseconds check (one for utimes functions that allows UTIME_OMIT and UTIME_NOW, one for other uses that doesn't). (utimes functions are also a case where a negative tv_sec is perfectly reasonable, but EINVAL is needed if the value is outside a filesystem-specific range - "A new file timestamp would be a value whose tv_sec component is not a value supported by the file system.".)