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]

Date:	Tue, 29 Mar 2016 21:30:29 +0200
From:	Arnd Bergmann <arnd@...db.de>
To:	Joseph Myers <joseph@...esourcery.com>
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 Tuesday 29 March 2016 15:54:52 Joseph Myers wrote:
> 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.

Right, makes sense.

> 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.

How do we do it then? Should we just define __USE_FILE_OFFSET64
unconditionally for all new 32-bit architectures and leave the
code dealing with 32-bit off_t/ino_t in place but unreachable, to
minimize the differences?

Or should all the obsolete types be defined the same way as their
replacements so we have 64-bit __OFF_T_TYPE/__INO_T_TYPE
and use the same binary implementation regardless of FILE_OFFSET_BITS?

	Arnd