On Wed, Jan 24, 2018 at 3:56 AM, Arnd Bergmann [off-list ref] wrote:

On Tue, Jan 23, 2018 at 5:25 PM, Deepa Dinamani [off-list ref] wrote:

quoted

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