linux-kernel - new architectures, time_t __kernel_long

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-Id: <201211141218.02105.arnd@arndb.de>
Date:	Wed, 14 Nov 2012 12:18:01 +0000
From:	Arnd Bergmann <arnd@...db.de>
To:	linux-arch@...r.kernel.org
Cc:	Vineet.Gupta1@...opsys.com, linux-kernel@...r.kernel.org,
	James Hogan <james.hogan@...tec.com>,
	"H. Peter Anvin" <hpa@...or.com>
Subject: new architectures, time_t __kernel_long_t

Since we are in the review phase for two new architectures that we
should be merging into the mainline kernel, I think we need to
come up with a solution for making them use a proper 64-bit time_t.

Right now, the only 32-bit user space interface we have to use 64-bit
time_t is the x32 side of x86-64, and that works by overriding all
"long" sized types to be 64 bit at the ABI level, which we don't
want for pure 32 bit architectures.

I would suggest we make 64-bit time_t, clock_t and suseconds_t the
default in include/asm-generic/posix_types.h and change all existing
32 bit users of that file to provide an override to define these
as "long".

The other types that are used as 64 bit on x32 are ino_t, nlink_t,
size_t, ssize_t, ptrdiff_t, and off_t.

Obviously, we want to use 64-bit off_t, but this is achieved already
through loff_t, which is used in all places in the asm-generic
ABI anyway (the syscalls using off_t are stripped out). I don't
think we want to have the other ones set to 64 bit on ARC or Meta,
although I'm not 100% sure about ino_t and nlink_t.

	Arnd
--
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/