On Wed, Jan 24, 2018 at 3:56 AM, Arnd Bergmann <arnd@xxxxxxxx> wrote: > On Tue, Jan 23, 2018 at 5:25 PM, Deepa Dinamani <deepa.kernel@xxxxxxxxx> wrote: >> >> I checked POSIX again. There is no mention of tv_nsec being positive >> always for utimes. >> And, the long term plan is to replace all the callers of >> timespec_trunc() to use this new api instead for filesystems. >> So this will need to be fixed. I will fix this and post an update. > > I found this on > http://pubs.opengroup.org/onlinepubs/9699919799/functions/utimes.html > > ERRORS > These functions shall fail if: > ... > [EINVAL] > Either of the times argument structures specified a tv_nsec value that was > neither UTIME_NOW nor UTIME_OMIT, and was a value less than zero or > greater than or equal to 1000 million. The thing is, we shouldn't check the standards, we should check what we actually _do_. And what we actually _do_ is to have a tv_nsec that is of type "long", and while we do have a timespec64_valid(const struct timespec64 *ts) and fs/utimes.c has a 'nsec_valid()' that apparently the utimes* family of system calls all do end up using, I'm more worried about something where we don't. Because I'm almost certain that we've had cases where we just normalize things after-the-fact. This all likely isn't a big deal, but it does end up worrying me if we then _depend_ on that granularity thing actually giving the proper granularity even for odd inputs. If they can happen. Maybe we don't care? Linus
