linux-kernel - 64-bit time on 32-bit systems

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] [day] [month] [year] [list]

Message-ID: <4F32EAD8.6020504@zytor.com>
Date:	Wed, 08 Feb 2012 13:36:24 -0800
From:	"H. Peter Anvin" <hpa@...or.com>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
CC:	Arnd Bergmann <arnd@...db.de>,
	Christoph Hellwig <hch@...radead.org>,
	LKML <linux-kernel@...r.kernel.org>,
	"H.J. Lu" <hjl.tools@...il.com>, Ingo Molnar <mingo@...e.hu>,
	Thomas Gleixner <tglx@...utronix.de>,
	Richard Kuo <rkuo@...eaurora.org>,
	Mark Salter <msalter@...hat.com>,
	Jonas Bonn <jonas@...thpole.se>,
	Tobias Klauser <tklauser@...tanz.ch>,
	"David S. Miller" <davem@...emloft.net>,
	"H.J. Lu" <hjl.tools@...il.com>
Subject: 64-bit time on 32-bit systems

Resuming a long-stuck discussion...

On 08/31/2011 10:19 AM, Linus Torvalds wrote:
> On Wed, Aug 31, 2011 at 10:09 AM, H. Peter Anvin <hpa@...or.com> wrote:
>>>
>>> I suspect only sane solution to this (having thought about it some
>>> more) is to just say "POSIX is f*^&ing wrong".
>>
>> Urk.  Someone had the bright idea of defining tv_nsec as "long" in the
>> standard, whereas tv_usec is suseconds_t.  F**** brilliant, and more
>> than a little bit stupid.
> 
> I think tv_nsec was just overlooked, and people thought "it has no
> legacy users that were 'int', so we'll just leave it at 'long', which
> is guaranteed to be enough for nanoseconds that only needs a range of
> 32 bits".
> 
> In contrast, tv_usec probably *does* have legacy users that are "int".
> 
> So POSIX almost certainly only looked backwards, and never thought
> about users who would need to make it "long long" for compatibility
> reasons.
> 
> The fact that *every*other*related*field* in POSIX/SuS has a typedef
> exactly for these kinds of reasons just shows how stupid that "long
> tv_nsec" thing is.
> 
> I suspect that on Linux we can just say "tv_nsec" is suseconds_t too.
> Then we can make time_t and suseconds_t just match, and be "__s64" on
> all new platforms.
> 

So I somewhat accidentally stumbled onto what appears to the the reason
for this while cleaning up posix_types.h last night.

The problem at hand seems to be that suseconds_t is 32 bits on SPARC64.
 This appears to be the case in both Linux and Solaris, which is
probably why struct timespec has "long" instead of suseconds_t (Sun
always have been prominent on the POSIX committee.)

As such, I don't think we can redefine struct timespec to have
suseconds_t for the nanosecond field, even on Linux.  We could define
snseconds_t, or we would have to do something really ugly like define a
padding field when on a 32-bit platform (which the kernel would then
have to ignore when reading from userspace by truncating the 64-bit
value rather than signaling an error if the upper 32 bits are set.)

snseconds_t seems semi-reasonable to me... I guess we'd have to push
that at the POSIX people.  Fortunately it shouldn't break anything to
have it be a wider type than is otherwise necessary.

	-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/