Re: [PATCH v8 00/20] ILP32 for ARM64

[Bamvor Zhang]

Hi, Yury

As I left huawei few month ago. My account of linaro is invalid. You
could send to my personal email(bamv2...@gmail.com).

Sorry for inconvenience.

Regards

Bamvor

On Fri, Feb 2, 2018 at 4:16 PM, Yury Norov  wrote:
> Hi Catalin, all
>
> (Exclude Bamvor as his email became invalid)
>
> This is 4.15-based kernel.
> https://github.com/norov/linux/commits/ilp32-4.15
>
> I tested it with LTP, no regressions found.
>
> Kernel v4.15 incorporates SVE series from Dave Martin, so I updated ILP32
> patches to agree with it. SVE-related changes are mostly in patches:
> arm64: ilp32: introduce ilp32-specific handlers for sigframe and ucontext
> arm64: signal32: move ilp32 and aarch32 common code to separated file
> arm64: signal: share lp64 signal structures and routines to ilp32
> arm64: ilp32: add sys_ilp32.c and a separate table (in entry.S) to use it
>
> Dave kindly reviewed that patches and proposed improvements:
> https://www.spinics.net/lists/arm-kernel/msg629221.html
>
> There's no ABI-related changes proposed, or urgent fixes; so I'll rework
> signal subsystem during 4.16 cycle.
>
> Are there any news with upstreaming this series?
>
> Thanks,
> Yury
>
> On Mon, Jun 19, 2017 at 06:49:43PM +0300, Yury Norov wrote:
>> This series enables aarch64 with ilp32 mode.
>>
>> As supporting work, it introduces ARCH_32BIT_OFF_T configuration
>> option that is enabled for existing 32-bit architectures but disabled
>> for new arches (so 64-bit off_t userspace type is used by new userspace).
>> Also it deprecates getrlimit and setrlimit syscalls prior to prlimit64.
>>
>> This version is based on linux-next from 2017-06-16. It works with
>> glibc-2.25, and tested with LTP, glibc testsuite, trinity, lmbench,
>> CPUSpec.
>>
>> Patches 1, 2, 3 and 8 are general, and may be applied separately.
>>
>> Kernel, GLIBC and OpenSUSE-based distro:
>> https://github.com/norov/linux/tree/ilp32-20170616.0
>> https://github.com/norov/glibc/tree/dev9
>> https://build.opensuse.org/project/show/devel:ARM:Factory:Contrib:ILP32
>>
>> (GLIBC patches are managed by Steve Ellcey, so my tree is only for
>> reference.)
>>
>> Changes:
>> v3: https://lkml.org/lkml/2014/9/3/704
>> v4: https://lkml.org/lkml/2015/4/13/691
>> v5: https://lkml.org/lkml/2015/9/29/911
>> v6: https://lkml.org/lkml/2016/5/23/661
>> v7: https://lkml.org/lkml/2017/1/9/213
>> v8: - off_t referred in patches 2 and 13 stands for userspace type which is
>>   underlined in corresponding patch comments and ARCH_32BIT_OFF_T config
>>   option description;
>> - __IGNORE_getrlimit and __IGNORE_setrlimit are added to
>>   scripts/checksyscalls.sh (patch 3);
>> - for CONFIG_COMPAT, bool changed to def_bool y and 'select COMPAT' is
>>   dropped for AARCH32_EL0 and ARM64_ILP32 optiond (patches 5 and 20);
>> - x19 register is used to load TSK_TI_FLAGS in svc path in
>>   arch/arm64/kernel/entry.S to avoid register clobbering (patch 14).
>> - ilp32 vdso-related files are syncronized wirh lp64 ones, mostly 
>> Makefiles
>>   (patch 19);
>> - in arch/arm64/mm/mmap.c, arch_mmap_rnd() swithed to use 
>> is_compat_task()
>>   (patch 9);
>> - rebased on next-20170616.
>>
>> Andrew Pinski (6):
>>   arm64: rename COMPAT to AARCH32_EL0 in Kconfig
>>   arm64: ensure the kernel is compiled for LP64
>>   arm64:uapi: set __BITS_PER_LONG correctly for ILP32 and LP64
>>   arm64: ilp32: add sys_ilp32.c and a separate table (in entry.S) to use
>> it
>>   arm64: ilp32: introduce ilp32-specific handlers for sigframe and
>> ucontext
>>   arm64:ilp32: add ARM64_ILP32 to Kconfig
>>
>> Philipp Tomsich (1):
>>   arm64:ilp32: add vdso-ilp32 and use for signal return
>>
>> Yury Norov (13):
>>   compat ABI: use non-compat openat and open_by_handle_at variants
>>   32-bit userspace ABI: introduce ARCH_32BIT_OFF_T config option
>>   asm-generic: Drop getrlimit and setrlimit syscalls from default list
>>   arm64: ilp32: add documentation on the ILP32 ABI for ARM64
>>   thread: move thread bits accessors to separated file
>>   arm64: introduce is_a32_task and is_a32_thread (for AArch32 compat)
>>   arm64: ilp32: add is_ilp32_compat_{task,thread} and TIF_32BIT_AARCH64
>>   arm64: introduce binfmt_elf32.c
>>   arm64: ilp32: introduce binfmt_ilp32.c
>>   arm64: ilp32: share aarch32 syscall handlers
>>   arm64: signal: share lp64 signal routines to ilp32
>>   arm64: signal32: move ilp32 and aarch32 common code to separated file
>>   arm64: ptrace: handle ptrace_request differently for aarch32 and ilp32
>>
>>  Documentation/arm64/ilp32.txt |  45 +++
>>  arch/Kconfig  |  15 +++
>>  arch/arc/Kconfig  |   1 +
>>  arch/arc/include/uapi/asm/unistd.h|   1 +
>>  arch/arm/Kconfig  |   1 +
>>  arch/arm64/Kconfig|  17 ++-
>>  arch/arm64/Makefile   |   8 ++
>>  

Re: [PATCH v8 00/20] ILP32 for ARM64

[Yury Norov]

Hi Catalin, all

(Exclude Bamvor as his email became invalid)

This is 4.15-based kernel.
https://github.com/norov/linux/commits/ilp32-4.15

I tested it with LTP, no regressions found.

Kernel v4.15 incorporates SVE series from Dave Martin, so I updated ILP32
patches to agree with it. SVE-related changes are mostly in patches:
arm64: ilp32: introduce ilp32-specific handlers for sigframe and ucontext
arm64: signal32: move ilp32 and aarch32 common code to separated file
arm64: signal: share lp64 signal structures and routines to ilp32
arm64: ilp32: add sys_ilp32.c and a separate table (in entry.S) to use it

Dave kindly reviewed that patches and proposed improvements:
https://www.spinics.net/lists/arm-kernel/msg629221.html

There's no ABI-related changes proposed, or urgent fixes; so I'll rework
signal subsystem during 4.16 cycle.

Are there any news with upstreaming this series?

Thanks,
Yury

On Mon, Jun 19, 2017 at 06:49:43PM +0300, Yury Norov wrote:
> This series enables aarch64 with ilp32 mode.
> 
> As supporting work, it introduces ARCH_32BIT_OFF_T configuration
> option that is enabled for existing 32-bit architectures but disabled
> for new arches (so 64-bit off_t userspace type is used by new userspace).
> Also it deprecates getrlimit and setrlimit syscalls prior to prlimit64.
> 
> This version is based on linux-next from 2017-06-16. It works with
> glibc-2.25, and tested with LTP, glibc testsuite, trinity, lmbench,
> CPUSpec.
> 
> Patches 1, 2, 3 and 8 are general, and may be applied separately.
> 
> Kernel, GLIBC and OpenSUSE-based distro:
> https://github.com/norov/linux/tree/ilp32-20170616.0
> https://github.com/norov/glibc/tree/dev9
> https://build.opensuse.org/project/show/devel:ARM:Factory:Contrib:ILP32
> 
> (GLIBC patches are managed by Steve Ellcey, so my tree is only for
> reference.)
> 
> Changes:
> v3: https://lkml.org/lkml/2014/9/3/704
> v4: https://lkml.org/lkml/2015/4/13/691
> v5: https://lkml.org/lkml/2015/9/29/911
> v6: https://lkml.org/lkml/2016/5/23/661
> v7: https://lkml.org/lkml/2017/1/9/213
> v8: - off_t referred in patches 2 and 13 stands for userspace type which is
>   underlined in corresponding patch comments and ARCH_32BIT_OFF_T config
>   option description;
> - __IGNORE_getrlimit and __IGNORE_setrlimit are added to
>   scripts/checksyscalls.sh (patch 3);
> - for CONFIG_COMPAT, bool changed to def_bool y and 'select COMPAT' is
>   dropped for AARCH32_EL0 and ARM64_ILP32 optiond (patches 5 and 20);
> - x19 register is used to load TSK_TI_FLAGS in svc path in
>   arch/arm64/kernel/entry.S to avoid register clobbering (patch 14).
> - ilp32 vdso-related files are syncronized wirh lp64 ones, mostly 
> Makefiles
>   (patch 19);
> - in arch/arm64/mm/mmap.c, arch_mmap_rnd() swithed to use is_compat_task()
>   (patch 9);
> - rebased on next-20170616.
> 
> Andrew Pinski (6):
>   arm64: rename COMPAT to AARCH32_EL0 in Kconfig
>   arm64: ensure the kernel is compiled for LP64
>   arm64:uapi: set __BITS_PER_LONG correctly for ILP32 and LP64
>   arm64: ilp32: add sys_ilp32.c and a separate table (in entry.S) to use
> it
>   arm64: ilp32: introduce ilp32-specific handlers for sigframe and
> ucontext
>   arm64:ilp32: add ARM64_ILP32 to Kconfig
> 
> Philipp Tomsich (1):
>   arm64:ilp32: add vdso-ilp32 and use for signal return
> 
> Yury Norov (13):
>   compat ABI: use non-compat openat and open_by_handle_at variants
>   32-bit userspace ABI: introduce ARCH_32BIT_OFF_T config option
>   asm-generic: Drop getrlimit and setrlimit syscalls from default list
>   arm64: ilp32: add documentation on the ILP32 ABI for ARM64
>   thread: move thread bits accessors to separated file
>   arm64: introduce is_a32_task and is_a32_thread (for AArch32 compat)
>   arm64: ilp32: add is_ilp32_compat_{task,thread} and TIF_32BIT_AARCH64
>   arm64: introduce binfmt_elf32.c
>   arm64: ilp32: introduce binfmt_ilp32.c
>   arm64: ilp32: share aarch32 syscall handlers
>   arm64: signal: share lp64 signal routines to ilp32
>   arm64: signal32: move ilp32 and aarch32 common code to separated file
>   arm64: ptrace: handle ptrace_request differently for aarch32 and ilp32
> 
>  Documentation/arm64/ilp32.txt |  45 +++
>  arch/Kconfig  |  15 +++
>  arch/arc/Kconfig  |   1 +
>  arch/arc/include/uapi/asm/unistd.h|   1 +
>  arch/arm/Kconfig  |   1 +
>  arch/arm64/Kconfig|  17 ++-
>  arch/arm64/Makefile   |   8 ++
>  arch/arm64/include/asm/compat.h   |  19 +--
>  arch/arm64/include/asm/elf.h  |  40 ++
>  arch/arm64/include/asm/fpsimd.h   |   2 +-
>  arch/arm64/include/asm/ftrace.h   |   2 +-
>  arch/arm64/include/asm/hwcap.h|   6 +-
>  arch/arm64/include/asm/is_compat.h|  90 ++
>  

Re: [PATCH v8 00/20] ILP32 for ARM64

[Catalin Marinas]

Hi Yury,

On Thu, Nov 16, 2017 at 02:11:30PM +0300, Yury Norov wrote:
> This is ILP32 patches on top of 4.14 kernel:
> https://github.com/norov/linux/commits/ilp32-4.14
> 
> I tested the series with LTP lite built by Linaro toolchain, and no
> regressions found.

Thanks. I gave it a try as well with LTP and pushed a staging/ilp32-4.14
branch to the arm64 tree on git.kernel.org. BTW, you've added two random
patches on top of this branch (which I removed).

> By the way, do you have plans to upstream arch subseries? 
> https://lkml.org/lkml/2017/9/25/574

I was hoping Arnd would pick them up since they are rather UAPI specific
than arm64.

BTW, I wonder whether the nds32 patches actually follow the proposed
defaults in your patches like force_o_largefile() and get/setrlimit:

https://lkml.org/lkml/2017/11/27/474

(I haven't reviewed the nds32 patches in detail though)

-- 
Catalin
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v8 00/20] ILP32 for ARM64

[Yury Norov]

Hi Catalin, Arnd, all,

This is ILP32 patches on top of 4.14 kernel:
https://github.com/norov/linux/commits/ilp32-4.14

I tested the series with LTP lite built by Linaro toolchain, and no
regressions found.

By the way, do you have plans to upstream arch subseries? 
https://lkml.org/lkml/2017/9/25/574

Yury
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v8 00/20] ILP32 for ARM64

[Catalin Marinas]

On Mon, Sep 04, 2017 at 02:54:50PM +0300, Yury Norov wrote:
> This is 4.13-based and next-20170901-based ilp32 patches. 
> https://github.com/norov/linux/tree/ilp32-4.13

Thanks. I'll mirror it on kernel.org sometime this week after doing some
tests (I've been mostly away for the past two weeks).

Regarding the generic patches in this series, could you please post them
to linux-arch (without the whole ILP32 series)? It would be good to get
them merged for 4.15.

-- 
Catalin
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v8 00/20] ILP32 for ARM64

[Yury Norov]

Hi all,

Linaro has announced the support for ILP32-enabled cross-toolchain:
https://lists.linaro.org/pipermail/linaro-toolchain/2017-September/006247.html

Files:
http://snapshots.linaro.org/components/toolchain/binaries/7.1-2017.08-rc1/aarch64-linux-gnu_ilp32/

Yury

On Mon, Jun 19, 2017 at 06:49:43PM +0300, Yury Norov wrote:
> This series enables aarch64 with ilp32 mode.
> 
> As supporting work, it introduces ARCH_32BIT_OFF_T configuration
> option that is enabled for existing 32-bit architectures but disabled
> for new arches (so 64-bit off_t userspace type is used by new userspace).
> Also it deprecates getrlimit and setrlimit syscalls prior to prlimit64.
> 
> This version is based on linux-next from 2017-06-16. It works with
> glibc-2.25, and tested with LTP, glibc testsuite, trinity, lmbench,
> CPUSpec.
> 
> Patches 1, 2, 3 and 8 are general, and may be applied separately.
> 
> Kernel, GLIBC and OpenSUSE-based distro:
> https://github.com/norov/linux/tree/ilp32-20170616.0
> https://github.com/norov/glibc/tree/dev9
> https://build.opensuse.org/project/show/devel:ARM:Factory:Contrib:ILP32
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v8 00/20] ILP32 for ARM64

[Yury Norov]

On Mon, Aug 21, 2017 at 01:21:24PM +0300, Yury Norov wrote:
> On Tue, Aug 08, 2017 at 02:34:11PM +0100, Catalin Marinas wrote:
> > On Mon, Jul 24, 2017 at 02:26:24PM +0300, Yury Norov wrote:
> > > This is the 4.12 and linux-next - based kernel patches:
> > > https://github.com/norov/linux/tree/ilp32-4.12
> > > https://github.com/norov/linux/tree/ilp32-20170724
> > 
> > I published the 4.12 branch here:
> > 
> > https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git/log/?h=staging/ilp32-4.12
> > 
> > (or git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git 
> > staging/ilp32-4.12)
> > 
> > There are two patches on top, one to fix SET_PERSONALITY and the other
> > to make ILP32 default y since you'd expect people using this branch to
> > need such option enabled.
> > 
> > I'll publish a 4.13-based branch when the corresponding kernel version
> > is released.
> 
> Hi Catalin,
> 
> This is the rc-6 based ilp32 series:
> https://github.com/norov/linux/tree/ilp32-4.13-rc6
> 
> It includes latest version of SET_PERSONALITY() rework:
> https://www.spinics.net/lists/arm-kernel/msg602005.html
> 
> All patches prior to 3fc85ee96eb8 ("arm64: ilp32: add documentation on
> the ILP32 ABI for ARM64") are looking not ilp32-specific and may be
> applied independently.
> 
> It also includes your patch "arm64: ilp32: Make the Kconfig option
> default y" on the top of series.
> 
> Yury

Hi Catalin, all,

This is 4.13-based and next-20170901-based ilp32 patches. 
https://github.com/norov/linux/tree/ilp32-4.13
https://github.com/norov/linux/tree/ilp32-20170901

Next-based series includes the patch that moves TASK_* definitions to


Also, Szabolcs has created arm/ilp32 branch for glibc.
https://sourceware.org/glibc/wiki/GlibcGit/arm_namespace

Yury
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v8 00/20] ILP32 for ARM64

[Yury Norov]

On Tue, Aug 08, 2017 at 02:34:11PM +0100, Catalin Marinas wrote:
> On Mon, Jul 24, 2017 at 02:26:24PM +0300, Yury Norov wrote:
> > This is the 4.12 and linux-next - based kernel patches:
> > https://github.com/norov/linux/tree/ilp32-4.12
> > https://github.com/norov/linux/tree/ilp32-20170724
> 
> I published the 4.12 branch here:
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git/log/?h=staging/ilp32-4.12
> 
> (or git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git 
> staging/ilp32-4.12)
> 
> There are two patches on top, one to fix SET_PERSONALITY and the other
> to make ILP32 default y since you'd expect people using this branch to
> need such option enabled.
> 
> I'll publish a 4.13-based branch when the corresponding kernel version
> is released.

Hi Catalin,

This is the rc-6 based ilp32 series:
https://github.com/norov/linux/tree/ilp32-4.13-rc6

It includes latest version of SET_PERSONALITY() rework:
https://www.spinics.net/lists/arm-kernel/msg602005.html

All patches prior to 3fc85ee96eb8 ("arm64: ilp32: add documentation on
the ILP32 ABI for ARM64") are looking not ilp32-specific and may be
applied independently.

It also includes your patch "arm64: ilp32: Make the Kconfig option
default y" on the top of series.

Yury
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v8 00/20] ILP32 for ARM64

[Catalin Marinas]

On Mon, Jul 24, 2017 at 02:26:24PM +0300, Yury Norov wrote:
> This is the 4.12 and linux-next - based kernel patches:
> https://github.com/norov/linux/tree/ilp32-4.12
> https://github.com/norov/linux/tree/ilp32-20170724

I published the 4.12 branch here:

https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git/log/?h=staging/ilp32-4.12

(or git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git 
staging/ilp32-4.12)

There are two patches on top, one to fix SET_PERSONALITY and the other
to make ILP32 default y since you'd expect people using this branch to
need such option enabled.

I'll publish a 4.13-based branch when the corresponding kernel version
is released.

Thanks.

-- 
Catalin
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v8 00/20] ILP32 for ARM64

[Yury Norov]

Hi Catalin,

On Thu, Jul 27, 2017 at 06:12:22PM +0100, Catalin Marinas wrote:
> Hi Yury,
> 
> On Mon, Jul 24, 2017 at 02:26:24PM +0300, Yury Norov wrote:

[...]

> > This is the 4.12 and linux-next - based kernel patches:
> > https://github.com/norov/linux/tree/ilp32-4.12
> > https://github.com/norov/linux/tree/ilp32-20170724
> 
> Thanks. I'll publish the 4.12-based branch sometime next week.
> 
> At this stage I don't see much value in a linux-next based ILP32. I
> would rather like to see a 4.13-rc3 based one, in preparation for a 4.13
> branch once released.
> 
> > Should I resend kernel patches to LKML, or links above are enough for
> > you?
> 
> The 4.12 link is ok. However, could you please post a 4.13-rcX based
> series, maybe split in two so that a few generic patches can be merged
> in 4.14?

This is the 4.13-rc3 - based branch:
https://github.com/norov/linux/tree/ilp32-4.13-rc3

Patches prior to 52315bc30f4967 ("arm64: ilp32: add documentation on
the ILP32 ABI for ARM64") are looking like generic. 

Note that this series includes the patch "ptrace: Add compat
PTRACE_{G,S}ETSIGMASK handlers":
https://patchwork.kernel.org/patch/9817343/

It is still under discussion in maillist. If it will be rejected, we'd
rework arm64 ptrace accordingly. 

> Given the reworking of the sigcontext code in 4.13, it would be
> good to review the ILP32 changes in this area again.

Thanks, I forgot to mention it in previous email. Changes are mostly located in
patches d87e8ed73d59 ("arm64: signal: share lp64 signal structures and routines
to ilp32") and 99c30e5df3f4 ("arm64: ilp32: introduce ilp32-specific handlers
for sigframe and ucontext"). All reviews are appreciated.

Yury
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v8 00/20] ILP32 for ARM64

[Catalin Marinas]

Hi Yury,

On Mon, Jul 24, 2017 at 02:26:24PM +0300, Yury Norov wrote:
> On Fri, Jul 07, 2017 at 06:11:36PM +0100, Catalin Marinas wrote:
> > On Fri, Jul 07, 2017 at 12:59:02AM +0300, Yury Norov wrote:
> > > If so, I would like to ask you to do the first ILP32 community poll
> > > now, not in 6 months. So we'll collect opinions and requests from
> > > people interested in ILP32, and in 6 month will be able to check the
> > > progress. I would like to see this thread public because if we are not
> > > taking ILP32 to official sources right now, this is the only way to
> > > inform people that the project exists and is ready to use.
> > 
> > That's an ongoing process, I'm not going to ask for people's opinion
> > every 6 months. It's just that I will revisit periodically the progress
> > on automated testing, public availability of a cross-toolchain,
> > Tested/Acked/Reviewed-by tags on these patches from interested parties.
> > Since I haven't seen any of these now, I don't see any point in asking.
> > 
> > To be clear, I'm not really interested in "we need this too" opinions, I
> > get lots of these via the marketing channels. I'm looking for actual
> > users with a long-term view of making/keeping ILP32 a first class ABI.
> 
> From my side, there are people who ask me for help with ilo32, and who
> write from big companies mailservers. But they don't want to ask
> their questions publicly for some reason. From my point of view, there
> is not so big but stable interest in ILP32.

It would be nice if they were more open about what they need/use.

> This is the 4.12 and linux-next - based kernel patches:
> https://github.com/norov/linux/tree/ilp32-4.12
> https://github.com/norov/linux/tree/ilp32-20170724

Thanks. I'll publish the 4.12-based branch sometime next week.

At this stage I don't see much value in a linux-next based ILP32. I
would rather like to see a 4.13-rc3 based one, in preparation for a 4.13
branch once released.

> Should I resend kernel patches to LKML, or links above are enough for
> you?

The 4.12 link is ok. However, could you please post a 4.13-rcX based
series, maybe split in two so that a few generic patches can be merged
in 4.14? Given the reworking of the sigcontext code in 4.13, it would be
good to review the ILP32 changes in this area again.

Thanks.

-- 
Catalin
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v8 00/20] ILP32 for ARM64

[Yury Norov]

Hi Catalin,

Hope you spent your vacation well.

On Fri, Jul 07, 2017 at 06:11:36PM +0100, Catalin Marinas wrote:
> Hi Yury,
> 
> Just a quick reply as I'm about to go on holiday for the next two weeks.
> 
> On Fri, Jul 07, 2017 at 12:59:02AM +0300, Yury Norov wrote:
> > On Thu, Jun 29, 2017 at 05:10:36PM +0100, Catalin Marinas wrote:
> > > On Mon, Jun 19, 2017 at 06:49:43PM +0300, Yury Norov wrote:
> > > > This series enables aarch64 with ilp32 mode.
> > > 
> > > What I'd like to propose is that Will and I (as arm64 maintainers, maybe
> > > with with the help of others including this series' authors) take over
> > > the series and push it to a staging branch under the arm64 kernel on
> > > git.kernel.org. This is aimed as a commitment to keep the ABI *stable*
> > > and will be rebased with every kernel release (starting with 4.13). The
> > > decision to merge upstream will be revisited every 6 months, assessing
> > > the progress on the points I mentioned above, with a time limit of 2
> > > years when, if still not upstream, we will stop maintaining such branch.
> > 
> > Thanks for the email. I appreciate your concern about long-term
> > support load for a new ABI. I also think that stabilizing the ABI
> > is a good idea.
> > 
> > At this point, most people expect the ABI to not change unless
> > critical issues are uncovered. IMO, if there is a good technical reason
> > to change the ABI -- the change will happen even on the "staging" branch.
> 
> What I would like is that we change the ABI *only* if there is a serious
> bug, otherwise we should try hard to keep it stable. The "good technical
> reason" can be subjective (i.e. let's pass 64-bit arguments in a single
> register because some benchmark is slightly faster; with a wider user
> base, we may get more suggestions for ABI changes that we should
> reject).
> 
> > And vise-versa, if there is no need for a change, the ABI will be stable
> > on my local branch, just like on staging branch you propose. I think it
> > will be that way until there will appear strong community of users who
> > will resist the changing of ABI. From this point of view, I don't see
> > major difference for ILP32 where to host the patchset.
> 
> If we don't treat the ABI as stable now, regardless of the number of
> users, then it is not ready for upstream (we already have a user in the
> openSUSE build).
> 
> The arm64 git.kernel.org suggestion was more of an endorsement from the
> maintainers that the ABI is stable. If you want to maintain it in your
> own tree, that's fine by me. If you want wider visibility, we could
> mirror it to git.kernel.org (though given how many trees are there, it
> may not mean much).

I fully agree with your suggestion and think that it will be the big
support for the project. I only want to clarity some details. But it
doesn't mean I'm skeptic with it.

> > Is my understanding correct that you, Will and me will be responsible
> > for rebasing and maintainance of patches? To be clear, this it not an
> > automatic task - sometimes simple rebase take the whole day of my time,
> > and I rebase almost every week. The rebase in 2-month timeframe may become
> > unpredictable task, by time and amount of work. I think you understand what
> > I mean, as once before you already told that the series is too intrusive.
> 
> I am fully aware there is significant effort to rebase the series and if
> you can help maintain such branch it would be great. I don't see the
> point of rebasing weekly though and it's not just the git handling
> process but doing the validation of such branch, regression testing etc.
> 
> If it's too time consuming, we could do it only for LTS releases.
> 
> > To make it more easy for maintainance, I would suggest to split the series
> > to 3 parts:
> >  - arch and generic patches that not related to ilp32 or arm64 (already
> >done);
> 
> That's fine.
> 
> >  - arm64 patches that do cleanup and refactoring in aim to apply
> >ilp32 patches smoothly, but not ilp32-specific;
> 
> If there are such changes, that's fine. However, I wouldn't merge the
> AARCH32_EL0 #ifdef'ery since it's unnecessary if we never merge the
> ILP32 patches.
> 
> > If we'll follow your suggestion, does it mean that you expect the 4.12-based
> > branch from me soon to put on staging?
> 
> We can create one for 4.12 if you want (in about 2-3 weeks time when I'm
> back). If there is no rush we could aim for 4.13 (there are some
> non-trivial conflicts in the sigframe handling code as we are preparing
> it for SVE support).
> 
> > > The decision to merge upstream will be revisited every 6 months,
> > > assessing the progress on the points I mentioned above, with a time
> > > limit of 2 years
> > 
> > IIUC, this is your personal decision based on responses and comments
> > from community?
> 
> Yes, as arm64 kernel maintainer.
> 
> > If so, I would like to ask you to do the first ILP32 community poll
> > now, not in 6 months. So we'll collect opinions and 

Re: [PATCH v8 00/20] ILP32 for ARM64

[Catalin Marinas]

Hi Yury,

Just a quick reply as I'm about to go on holiday for the next two weeks.

On Fri, Jul 07, 2017 at 12:59:02AM +0300, Yury Norov wrote:
> On Thu, Jun 29, 2017 at 05:10:36PM +0100, Catalin Marinas wrote:
> > On Mon, Jun 19, 2017 at 06:49:43PM +0300, Yury Norov wrote:
> > > This series enables aarch64 with ilp32 mode.
> > 
> > What I'd like to propose is that Will and I (as arm64 maintainers, maybe
> > with with the help of others including this series' authors) take over
> > the series and push it to a staging branch under the arm64 kernel on
> > git.kernel.org. This is aimed as a commitment to keep the ABI *stable*
> > and will be rebased with every kernel release (starting with 4.13). The
> > decision to merge upstream will be revisited every 6 months, assessing
> > the progress on the points I mentioned above, with a time limit of 2
> > years when, if still not upstream, we will stop maintaining such branch.
> 
> Thanks for the email. I appreciate your concern about long-term
> support load for a new ABI. I also think that stabilizing the ABI
> is a good idea.
> 
> At this point, most people expect the ABI to not change unless
> critical issues are uncovered. IMO, if there is a good technical reason
> to change the ABI -- the change will happen even on the "staging" branch.

What I would like is that we change the ABI *only* if there is a serious
bug, otherwise we should try hard to keep it stable. The "good technical
reason" can be subjective (i.e. let's pass 64-bit arguments in a single
register because some benchmark is slightly faster; with a wider user
base, we may get more suggestions for ABI changes that we should
reject).

> And vise-versa, if there is no need for a change, the ABI will be stable
> on my local branch, just like on staging branch you propose. I think it
> will be that way until there will appear strong community of users who
> will resist the changing of ABI. From this point of view, I don't see
> major difference for ILP32 where to host the patchset.

If we don't treat the ABI as stable now, regardless of the number of
users, then it is not ready for upstream (we already have a user in the
openSUSE build).

The arm64 git.kernel.org suggestion was more of an endorsement from the
maintainers that the ABI is stable. If you want to maintain it in your
own tree, that's fine by me. If you want wider visibility, we could
mirror it to git.kernel.org (though given how many trees are there, it
may not mean much).

> Is my understanding correct that you, Will and me will be responsible
> for rebasing and maintainance of patches? To be clear, this it not an
> automatic task - sometimes simple rebase take the whole day of my time,
> and I rebase almost every week. The rebase in 2-month timeframe may become
> unpredictable task, by time and amount of work. I think you understand what
> I mean, as once before you already told that the series is too intrusive.

I am fully aware there is significant effort to rebase the series and if
you can help maintain such branch it would be great. I don't see the
point of rebasing weekly though and it's not just the git handling
process but doing the validation of such branch, regression testing etc.

If it's too time consuming, we could do it only for LTS releases.

> To make it more easy for maintainance, I would suggest to split the series
> to 3 parts:
>  - arch and generic patches that not related to ilp32 or arm64 (already
>done);

That's fine.

>  - arm64 patches that do cleanup and refactoring in aim to apply
>ilp32 patches smoothly, but not ilp32-specific;

If there are such changes, that's fine. However, I wouldn't merge the
AARCH32_EL0 #ifdef'ery since it's unnecessary if we never merge the
ILP32 patches.

> If we'll follow your suggestion, does it mean that you expect the 4.12-based
> branch from me soon to put on staging?

We can create one for 4.12 if you want (in about 2-3 weeks time when I'm
back). If there is no rush we could aim for 4.13 (there are some
non-trivial conflicts in the sigframe handling code as we are preparing
it for SVE support).

> > The decision to merge upstream will be revisited every 6 months,
> > assessing the progress on the points I mentioned above, with a time
> > limit of 2 years
> 
> IIUC, this is your personal decision based on responses and comments
> from community?

Yes, as arm64 kernel maintainer.

> If so, I would like to ask you to do the first ILP32 community poll
> now, not in 6 months. So we'll collect opinions and requests from
> people interested in ILP32, and in 6 month will be able to check the
> progress. I would like to see this thread public because if we are not
> taking ILP32 to official sources right now, this is the only way to
> inform people that the project exists and is ready to use.

That's an ongoing process, I'm not going to ask for people's opinion
every 6 months. It's just that I will revisit periodically the progress
on automated testing, public availability of a 

Re: [PATCH v8 00/20] ILP32 for ARM64

[Yury Norov]

Hi Catalin,

On Thu, Jun 29, 2017 at 05:10:36PM +0100, Catalin Marinas wrote:
> Hi Yury,
> 
> On Mon, Jun 19, 2017 at 06:49:43PM +0300, Yury Norov wrote:
> > This series enables aarch64 with ilp32 mode.
> 
> Thanks for putting this series together, I do appreciate the effort.
> There are still some review comments coming in but I'm happy with how
> the ABI looks now. I did some LTP testing (AArch64/LP64, AArch64/ILP32,
> AArch32) and benchmarking and didn't see any regressions (apart from an
> LTP bug with sync_file_range2). James Morse is working on reproducing
> similar testing in ARM. Szabolcs reported some glibc test-suite
> regressions on the libc-alpha list which I assume will be followed up.
> VDSO in C is another issue I'd like sorted but this is not strictly
> specific to ILP32 and can be done as a follow up. Note that I didn't run
> any big-endian tests, though this is something that needs doing.
> 
> Now, having agreed on the ABI and implementation very close to being
> ready doesn't necessarily make the code suitable for upstream. With my
> maintainer hat on, I'm trying to see where ILP32 will be in 2-5-10
> years, whether anyone still cares about it in this time frame. The
> difference from a driver or SoC support is that ABIs are very hard to
> revert, though are as (or even more) likely to bit-rot when not in use
> or regularly tested (we have the big-endian experience here).
> 
> There are two main aspects to make the code upstream-worthy:
> 
> 1. Actual/real users (current, future). I don't mean just a few distros
>showing that it can be done but actual/planned real deployments
> 
> 2. Long term testing/maintenance plan. This is not about kernel code
>maintenance but a healthy ILP32 ecosystem:
>a) readily available toolchains (x86-hosted and AArch64-hosted)
>b) filesystems (can be large distros like openSUSE or more
>   embedded-oriented like Yocto or OpenEmbedded)
>c) suitable continuous regression testing (kernel + userland)
>d) commitment from all parties involved (including ARM Ltd) to treat
>   the ILP32 ABI as a (nearly) first class citizen
> 
> It is pretty clear from private discussions that there are potential
> users but at the moment I can't tell if those would turn into real
> deployments of production systems. As for (2), the long term plans are
> not convincing (or I haven't spotted them yet), so I'd like to see the
> interested parties putting a plan together (something along the lines of
> kernelci.org + LTP, glibc buildbot).
> 
> What I'd like to propose is that Will and I (as arm64 maintainers, maybe
> with with the help of others including this series' authors) take over
> the series and push it to a staging branch under the arm64 kernel on
> git.kernel.org. This is aimed as a commitment to keep the ABI *stable*
> and will be rebased with every kernel release (starting with 4.13). The
> decision to merge upstream will be revisited every 6 months, assessing
> the progress on the points I mentioned above, with a time limit of 2
> years when, if still not upstream, we will stop maintaining such branch.
> 
> I am aware that the above proposal has an impact on the glibc patches
> since they will not merge a new ABI upstream until officially supported
> by the kernel. I cc'ed some of the glibc developers and they will follow
> up on the libc-alpha list.

Thanks for the email. I appreciate your concern about long-term
support load for a new ABI. I also think that stabilizing the ABI
is a good idea.

At this point, most people expect the ABI to not change unless
critical issues are uncovered. IMO, if there is a good technical reason
to change the ABI -- the change will happen even on the "staging" branch.
And vise-versa, if there is no need for a change, the ABI will be stable
on my local branch, just like on staging branch you propose. I think it
will be that way until there will appear strong community of users who
will resist the changing of ABI. From this point of view, I don't see
major difference for ILP32 where to host the patchset.

Is my understanding correct that you, Will and me will be responsible
for rebasing and maintainance of patches? To be clear, this it not an
automatic task - sometimes simple rebase take the whole day of my time,
and I rebase almost every week. The rebase in 2-month timeframe may become
unpredictable task, by time and amount of work. I think you understand what
I mean, as once before you already told that the series is too intrusive.
To make it more easy for maintainance, I would suggest to split the series
to 3 parts:
 - arch and generic patches that not related to ilp32 or arm64 (already
   done);
 - arm64 patches that do cleanup and refactoring in aim to apply
   ilp32 patches smoothly, but not ilp32-specific;
 - ilp32-specific patches.

I suggest that we push 1st and 2nd groups to linux-next as there is no
ilp32-specific code, and these changes don't add to the maintenance
overhead of the port. On the other 

Re: [PATCH v8 00/20] ILP32 for ARM64

[Catalin Marinas]

Hi Yury,

On Mon, Jun 19, 2017 at 06:49:43PM +0300, Yury Norov wrote:
> This series enables aarch64 with ilp32 mode.

Thanks for putting this series together, I do appreciate the effort.
There are still some review comments coming in but I'm happy with how
the ABI looks now. I did some LTP testing (AArch64/LP64, AArch64/ILP32,
AArch32) and benchmarking and didn't see any regressions (apart from an
LTP bug with sync_file_range2). James Morse is working on reproducing
similar testing in ARM. Szabolcs reported some glibc test-suite
regressions on the libc-alpha list which I assume will be followed up.
VDSO in C is another issue I'd like sorted but this is not strictly
specific to ILP32 and can be done as a follow up. Note that I didn't run
any big-endian tests, though this is something that needs doing.

Now, having agreed on the ABI and implementation very close to being
ready doesn't necessarily make the code suitable for upstream. With my
maintainer hat on, I'm trying to see where ILP32 will be in 2-5-10
years, whether anyone still cares about it in this time frame. The
difference from a driver or SoC support is that ABIs are very hard to
revert, though are as (or even more) likely to bit-rot when not in use
or regularly tested (we have the big-endian experience here).

There are two main aspects to make the code upstream-worthy:

1. Actual/real users (current, future). I don't mean just a few distros
   showing that it can be done but actual/planned real deployments

2. Long term testing/maintenance plan. This is not about kernel code
   maintenance but a healthy ILP32 ecosystem:
   a) readily available toolchains (x86-hosted and AArch64-hosted)
   b) filesystems (can be large distros like openSUSE or more
  embedded-oriented like Yocto or OpenEmbedded)
   c) suitable continuous regression testing (kernel + userland)
   d) commitment from all parties involved (including ARM Ltd) to treat
  the ILP32 ABI as a (nearly) first class citizen

It is pretty clear from private discussions that there are potential
users but at the moment I can't tell if those would turn into real
deployments of production systems. As for (2), the long term plans are
not convincing (or I haven't spotted them yet), so I'd like to see the
interested parties putting a plan together (something along the lines of
kernelci.org + LTP, glibc buildbot).

What I'd like to propose is that Will and I (as arm64 maintainers, maybe
with with the help of others including this series' authors) take over
the series and push it to a staging branch under the arm64 kernel on
git.kernel.org. This is aimed as a commitment to keep the ABI *stable*
and will be rebased with every kernel release (starting with 4.13). The
decision to merge upstream will be revisited every 6 months, assessing
the progress on the points I mentioned above, with a time limit of 2
years when, if still not upstream, we will stop maintaining such branch.

I am aware that the above proposal has an impact on the glibc patches
since they will not merge a new ABI upstream until officially supported
by the kernel. I cc'ed some of the glibc developers and they will follow
up on the libc-alpha list.

> As supporting work, it introduces ARCH_32BIT_OFF_T configuration
> option that is enabled for existing 32-bit architectures but disabled
> for new arches (so 64-bit off_t userspace type is used by new userspace).
> Also it deprecates getrlimit and setrlimit syscalls prior to prlimit64.
[...]
> Patches 1, 2, 3 and 8 are general, and may be applied separately.

These 4 patches should be merged independently, I don't see a point in
carrying them with the ILP32 series. Arnd, are you ok to push them
upstream?

BTW, patch 3 seems to never make it to the linux-arm-kernel list, I
guess too many on cc.

--
Catalin

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v8 00/20] ILP32 for ARM64

[Yury Norov]

This series enables aarch64 with ilp32 mode.

As supporting work, it introduces ARCH_32BIT_OFF_T configuration
option that is enabled for existing 32-bit architectures but disabled
for new arches (so 64-bit off_t userspace type is used by new userspace).
Also it deprecates getrlimit and setrlimit syscalls prior to prlimit64.

This version is based on linux-next from 2017-06-16. It works with
glibc-2.25, and tested with LTP, glibc testsuite, trinity, lmbench,
CPUSpec.

Patches 1, 2, 3 and 8 are general, and may be applied separately.

Kernel, GLIBC and OpenSUSE-based distro:
https://github.com/norov/linux/tree/ilp32-20170616.0
https://github.com/norov/glibc/tree/dev9
https://build.opensuse.org/project/show/devel:ARM:Factory:Contrib:ILP32

(GLIBC patches are managed by Steve Ellcey, so my tree is only for
reference.)

Changes:
v3: https://lkml.org/lkml/2014/9/3/704
v4: https://lkml.org/lkml/2015/4/13/691
v5: https://lkml.org/lkml/2015/9/29/911
v6: https://lkml.org/lkml/2016/5/23/661
v7: https://lkml.org/lkml/2017/1/9/213
v8: - off_t referred in patches 2 and 13 stands for userspace type which is
  underlined in corresponding patch comments and ARCH_32BIT_OFF_T config
  option description;
- __IGNORE_getrlimit and __IGNORE_setrlimit are added to
  scripts/checksyscalls.sh (patch 3);
- for CONFIG_COMPAT, bool changed to def_bool y and 'select COMPAT' is
  dropped for AARCH32_EL0 and ARM64_ILP32 optiond (patches 5 and 20);
- x19 register is used to load TSK_TI_FLAGS in svc path in
  arch/arm64/kernel/entry.S to avoid register clobbering (patch 14).
- ilp32 vdso-related files are syncronized wirh lp64 ones, mostly Makefiles
  (patch 19);
- in arch/arm64/mm/mmap.c, arch_mmap_rnd() swithed to use is_compat_task()
  (patch 9);
- rebased on next-20170616.

Andrew Pinski (6):
  arm64: rename COMPAT to AARCH32_EL0 in Kconfig
  arm64: ensure the kernel is compiled for LP64
  arm64:uapi: set __BITS_PER_LONG correctly for ILP32 and LP64
  arm64: ilp32: add sys_ilp32.c and a separate table (in entry.S) to use
it
  arm64: ilp32: introduce ilp32-specific handlers for sigframe and
ucontext
  arm64:ilp32: add ARM64_ILP32 to Kconfig

Philipp Tomsich (1):
  arm64:ilp32: add vdso-ilp32 and use for signal return

Yury Norov (13):
  compat ABI: use non-compat openat and open_by_handle_at variants
  32-bit userspace ABI: introduce ARCH_32BIT_OFF_T config option
  asm-generic: Drop getrlimit and setrlimit syscalls from default list
  arm64: ilp32: add documentation on the ILP32 ABI for ARM64
  thread: move thread bits accessors to separated file
  arm64: introduce is_a32_task and is_a32_thread (for AArch32 compat)
  arm64: ilp32: add is_ilp32_compat_{task,thread} and TIF_32BIT_AARCH64
  arm64: introduce binfmt_elf32.c
  arm64: ilp32: introduce binfmt_ilp32.c
  arm64: ilp32: share aarch32 syscall handlers
  arm64: signal: share lp64 signal routines to ilp32
  arm64: signal32: move ilp32 and aarch32 common code to separated file
  arm64: ptrace: handle ptrace_request differently for aarch32 and ilp32

 Documentation/arm64/ilp32.txt |  45 +++
 arch/Kconfig  |  15 +++
 arch/arc/Kconfig  |   1 +
 arch/arc/include/uapi/asm/unistd.h|   1 +
 arch/arm/Kconfig  |   1 +
 arch/arm64/Kconfig|  17 ++-
 arch/arm64/Makefile   |   8 ++
 arch/arm64/include/asm/compat.h   |  19 +--
 arch/arm64/include/asm/elf.h  |  40 ++
 arch/arm64/include/asm/fpsimd.h   |   2 +-
 arch/arm64/include/asm/ftrace.h   |   2 +-
 arch/arm64/include/asm/hwcap.h|   6 +-
 arch/arm64/include/asm/is_compat.h|  90 ++
 arch/arm64/include/asm/memory.h   |   5 +-
 arch/arm64/include/asm/processor.h|  11 +-
 arch/arm64/include/asm/ptrace.h   |   2 +-
 arch/arm64/include/asm/seccomp.h  |   2 +-
 arch/arm64/include/asm/signal32.h |   9 +-
 arch/arm64/include/asm/signal32_common.h  |  27 
 arch/arm64/include/asm/signal_common.h|  33 +
 arch/arm64/include/asm/signal_ilp32.h |  38 ++
 arch/arm64/include/asm/syscall.h  |   2 +-
 arch/arm64/include/asm/thread_info.h  |   4 +-
 arch/arm64/include/asm/unistd.h   |   6 +-
 arch/arm64/include/asm/vdso.h |   6 +
 arch/arm64/include/uapi/asm/bitsperlong.h |   9 +-
 arch/arm64/include/uapi/asm/unistd.h  |  13 ++
 arch/arm64/kernel/Makefile|   8 +-
 arch/arm64/kernel/asm-offsets.c   |   9 +-
 arch/arm64/kernel/binfmt_elf32.c  |  37 ++
 arch/arm64/kernel/binfmt_ilp32.c  |  85 +
 arch/arm64/kernel/cpufeature.c|   8 +-
 arch/arm64/kernel/cpuinfo.c   |   8 +-