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

Message-ID: <56FCD358.3030807@huawei.com>
Date:	Thu, 31 Mar 2016 15:35:52 +0800
From:	"Zhangjian (Bamvor)" <bamvor.zhangjian@...wei.com>
To:	Arnd Bergmann <arnd@...db.de>
CC:	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>,
	<joseph@...esourcery.com>, <gaoyongliang@...wei.com>,
	<schwidefsky@...ibm.com>, <Nathan_Lynch@...tor.com>,
	Bamvor Zhang Jian <bamvor.zhangjian@...aro.org>,
	<christoph.muellner@...obroma-systems.com>,
	"Zhangjian (Bamvor)" <bamvor.zhangjian@...wei.com>
Subject: Re: [RFC5 PATCH v6 00/21] ILP32 for ARM64



On 2016/3/29 21:27, Arnd Bergmann wrote:
> On Tuesday 29 March 2016 21:21:49 Zhangjian wrote:
>>>>>
>>>>> Then we could remove the __USE_FILE_OFFSET64 in stat.h and fcnt.h in
>>>>> aarch64. And truncate and ftruncate is same as truncate64 and
>>>>> ftruncate64.
>>>>
>>>> I don't know what the glibc developers prefer, but I think the
>>>> result needs to be something like that: either __OFF_T_TYPE is
>>>> defined as you write above as a 64-bit type, or the user-visible
>>>> off_t typedef unconditionally uses __OFF64_T_TYPE rather than
>>>> __OFF_T_TYPE.
>>>>
>>>
>>> I'm not the glibc developer as well, but I think it's OK.
>> IIUC, it is usually what glibc does.
>> If we want to define off_t to 64bit in ilp32, the follow syscall may
>> need to define as non-compat too:
>> sys_fadvise64
>> sys_sendfile
>> sys_sendfile64
>> sys_lseek
>> sys_splice
>> sys_sync_file_range2
>> sys_truncate
>> sys_ftruncate
>
> I'm not following here. Do you mean in the kernel or in glibc?
kernel.
>
> In the kernel, the list of syscalls is fine, because we already only
> provide syscalls passing loff_t as I said, and that is 64-bit.
Sorry I am lost here. I understand that the syscall passing loff_t
should wrap to 64bit syscall. But if we define off_t as 64bit,
then all the offset relative syscall should wrap to 64bit syscall.
>
> 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.
Agree. We should avoid the duplicated definition.

Regards

Bamvor

>
> 	Arnd
>