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.1603292010080.15654@digraph.polyomino.org.uk>
Date:	Tue, 29 Mar 2016 20:15:10 +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:

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

Defining __USE_FILE_OFFSET64 unconditionally would prevent glibc from 
building (see: how the patches a while back prototyping changing the 
default had to disable the change when glibc itself is built).  A change 
in the default, though desired (someone needs to pick up those patches 
together with the analysis done of possible impact on distributions), 
should not be tied to a new port, and would need to be discussed 
thoroughly on libc-alpha.

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

I think so (along with using wordsize-64 sysdeps directories as far as 
possible, like x32 does).  But design questions for a glibc port really 
belong on libc-alpha to get any sort of community consensus.

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