linux-kernel - Re: [PATCH] utimensat implementation

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <463149A8.6070408@redhat.com>
Date:	Thu, 26 Apr 2007 17:54:00 -0700
From:	Ulrich Drepper <drepper@...hat.com>
To:	Andrew Morton <akpm@...ux-foundation.org>
CC:	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] utimensat implementation

Andrew Morton wrote:
> Does the spec say what the OS should do if (ts_nsec => 1e9)?

Yes, return EINVAL.  We already do this.  It's just that now we have to
recognize two special values.

> OK, so there's no collision on ts_nsec if unnormalised timespecs are
> disallowed.

Indeed, that's the basis of using the special values.

I chose the values of the constants so that they are a) out of the way
of valid values and b) don't have to be adjusted for 32-bit compat code.

> But there's a potential collision on ts_sec?  Do we know what date that
> corresponds to?

No, there is no collision.  The tv_sec value is relevant.  The
UTIME_OMIT and UTIME_NOW value refers to the atime/mtime respectively,
not just the tv_nsec field of either.  It makes no sense to just set
tv_sec, the tv_nsec value would be basically random.

In my patch I'm testing that tv_sec is zero in case any of the special
values is used in the corresponding tv_nsec field.  That's more than the
standard currently requires but I think it's better and I try to get the
standard proposal changed.  If this doesn't happen I'll make appropriate
changes at userlevel for the "strictly POSIX" mode.

> Do you have a testcase app which can be used by arch maintainers?

Attached here.

-- 
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖

View attachment "utimensat-test.c" of type "text/x-csrc" (2912 bytes)

Download attachment "signature.asc" of type "application/pgp-signature" (252 bytes)