linux-kernel - Re: [RFC5 PATCH v6 00/21] ILP32 for ARM64

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

Message-ID: <alpine.DEB.2.10.1603291551420.20115@digraph.polyomino.org.uk>
Date:	Tue, 29 Mar 2016 15:54:52 +0000
From:	Joseph Myers <joseph@...esourcery.com>
To:	Arnd Bergmann <arnd@...db.de>
CC:	"Zhangjian (Bamvor)" <bamvor.zhangjian@...wei.com>,
	Yury Norov <ynorov@...iumnetworks.com>,
	<linux-arm-kernel@...ts.infradead.org>,
	Andreas Schwab <schwab@...e.de>, <young.liuyang@...wei.com>,
	<pinskia@...il.com>, <Prasun.Kapoor@...iumnetworks.com>,
	<catalin.marinas@....com>, <broonie@...nel.org>,
	"jijun (D)" <jijun2@...wei.com>, <heiko.carstens@...ibm.com>,
	<linux-kernel@...r.kernel.org>, <agraf@...e.de>,
	<klimov.linux@...il.com>, <jan.dakinevich@...il.com>,
	<gaoyongliang@...wei.com>, <schwidefsky@...ibm.com>,
	<Nathan_Lynch@...tor.com>,
	Bamvor Zhang Jian <bamvor.zhangjian@...aro.org>,
	<christoph.muellner@...obroma-systems.com>
Subject: Re: [RFC5 PATCH v6 00/21] ILP32 for ARM64

On Tue, 29 Mar 2016, Arnd Bergmann wrote:

> In glibc, I think we need to define fewer entry points, not more.
> Instead of having both lseek and lseek64, only one of them should
> be provided, and that should always take a 64-bit offset, calling
> into the kernel with the _llseek syscall entry.

lseek64 is part of the public API, on all platforms.  It should be aliased 
to lseek where possible.

Strictly, it would be possible to provide it in the API without it being 
part of the ABI, by arranging the headers so that calls to lseek64 result 
in objects with a reference to lseek (because it uses the off64_t typedef, 
it's not valid to declare it yourself rather than including a header that 
declares it).  I don't think it would be a good idea for a new 
sub-architecture port to try introducing such a difference from all other 
ports, however.

-- 
Joseph S. Myers
joseph@...esourcery.com