Re: [PATCH 1/2] Documentation/memory-barriers.txt: cross-reference "tools/memory-model/"

[Paul E. McKenney]

On Fri, Feb 02, 2018 at 10:12:48AM +0100, Andrea Parri wrote:
> Recent efforts led to the specification of a memory consistency model
> for the Linux kernel [1], which "can (roughly speaking) be thought of
> as an automated version of memory-barriers.txt" and which is (in turn)
> "accompanied by extensive documentation on its use and its design".
> 
> Make sure that the (occasional) reader of memory-barriers.txt will be
> aware of these developments.
> 
> [1] https://marc.info/?l=linux-kernel=151687290114799=2
> 
> Signed-off-by: Andrea Parri 

I am inclined to pull in something along these lines, but would like
some feedback on the wording, especially how "official" we want to
make the memory model to be.

Thoughts?

If I don't hear otherwise in a couple of days, I will pull this as is.

Thanx, Paul

> ---
>  Documentation/memory-barriers.txt | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/Documentation/memory-barriers.txt 
> b/Documentation/memory-barriers.txt
> index a863009849a3b..8cc3f098f4a7d 100644
> --- a/Documentation/memory-barriers.txt
> +++ b/Documentation/memory-barriers.txt
> @@ -17,7 +17,9 @@ meant as a guide to using the various memory barriers 
> provided by Linux, but
>  in case of any doubt (and there are many) please ask.
> 
>  To repeat, this document is not a specification of what Linux expects from
> -hardware.
> +hardware.  For such a specification, in the form of a memory consistency
> +model, and for documentation about its usage and its design, the reader is
> +referred to "tools/memory-model/".
> 
>  The purpose of this document is twofold:
> 
> -- 
> 2.7.4
> 

--
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 2/2] MAINTAINERS: list file memory-barriers.txt within the LKMM entry

[Andrea Parri]

On Fri, Feb 02, 2018 at 03:51:02PM -0800, Paul E. McKenney wrote:
> On Fri, Feb 02, 2018 at 10:13:42AM +0100, Andrea Parri wrote:
> > Now that a formal specification of the LKMM has become available to
> > the developer, some concern about how to track changes to the model
> > on the level of the "high-level documentation" was raised.
> > 
> > A first "mitigation" to this issue, suggested by Will, is to assign
> > maintainership (and responsibility!!)  of such documentation (here,
> > memory-barriers.txt) to the maintainers of the LKMM themselves.
> > 
> > Suggested-by: Will Deacon 
> > Signed-off-by: Andrea Parri 
> 
> Very good, thank you, queued!  Please see below for the usual commit-log
> rework.  BTW, in future submissions, could you please capitalize the
> first word after the colon (":") in the subject line?  It is all too
> easy for me to forget to change this, as Ingo can attest.  ;-)

Sorry, I'll do my best! ;-)


> 
> If we are going to continue to use the LKMM acronym, should we make the
> first line of the MAINTAINERS block look something like this?

I've no strong opinion about whether we should, but it makes sense to me.
(The acronym is currently defined (and heavily used) in explanation.txt.)

Thanks,
  Andrea


> 
>   LINUX KERNEL MEMORY CONSISTENCY MODEL (LKMM)
> 
> One alternative would be to start calling it LKMCM, though that does
> look a bit like a Roman numeral.  ;-)
> 
>   Thanx, Paul
> 
> 
> 
> commit 2f80571625dc2d1977acdef79267ba1645b07c53
> Author: Andrea Parri 
> Date:   Fri Feb 2 10:13:42 2018 +0100
> 
> MAINTAINERS: List file memory-barriers.txt within the LKMM entry
> 
> We now have a shiny new Linux-kernel memory model (LKMM) and the old
> tried-and-true Documentation/memory-barrier.txt.  It would be good to
> keep these automatically synchronized, but in the meantime we need at
> least let people know that they are related.  Will suggested adding the
> Documentation/memory-barrier.txt file to the LKMM maintainership list,
> thus making the LKMM maintainers responsible for both the old and the new.
> This commit follows Will's excellent suggestion.
> 
> Suggested-by: Will Deacon 
> Signed-off-by: Andrea Parri 
> Signed-off-by: Paul E. McKenney 
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index ba4dc08fbe95..e6ad9b44e8fb 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -8101,6 +8101,7 @@ L:  linux-ker...@vger.kernel.org
>  S:   Supported
>  T:   git git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git
>  F:   tools/memory-model/
> +F:   Documentation/memory-barriers.txt
>  
>  LINUX SECURITY MODULE (LSM) FRAMEWORK
>  M:   Chris Wright 
> 
--
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 2/2] MAINTAINERS: list file memory-barriers.txt within the LKMM entry

[Paul E. McKenney]

On Fri, Feb 02, 2018 at 10:13:42AM +0100, Andrea Parri wrote:
> Now that a formal specification of the LKMM has become available to
> the developer, some concern about how to track changes to the model
> on the level of the "high-level documentation" was raised.
> 
> A first "mitigation" to this issue, suggested by Will, is to assign
> maintainership (and responsibility!!)  of such documentation (here,
> memory-barriers.txt) to the maintainers of the LKMM themselves.
> 
> Suggested-by: Will Deacon 
> Signed-off-by: Andrea Parri 

Very good, thank you, queued!  Please see below for the usual commit-log
rework.  BTW, in future submissions, could you please capitalize the
first word after the colon (":") in the subject line?  It is all too
easy for me to forget to change this, as Ingo can attest.  ;-)

If we are going to continue to use the LKMM acronym, should we make the
first line of the MAINTAINERS block look something like this?

LINUX KERNEL MEMORY CONSISTENCY MODEL (LKMM)

One alternative would be to start calling it LKMCM, though that does
look a bit like a Roman numeral.  ;-)

Thanx, Paul



commit 2f80571625dc2d1977acdef79267ba1645b07c53
Author: Andrea Parri 
Date:   Fri Feb 2 10:13:42 2018 +0100

MAINTAINERS: List file memory-barriers.txt within the LKMM entry

We now have a shiny new Linux-kernel memory model (LKMM) and the old
tried-and-true Documentation/memory-barrier.txt.  It would be good to
keep these automatically synchronized, but in the meantime we need at
least let people know that they are related.  Will suggested adding the
Documentation/memory-barrier.txt file to the LKMM maintainership list,
thus making the LKMM maintainers responsible for both the old and the new.
This commit follows Will's excellent suggestion.

Suggested-by: Will Deacon 
Signed-off-by: Andrea Parri 
Signed-off-by: Paul E. McKenney 

diff --git a/MAINTAINERS b/MAINTAINERS
index ba4dc08fbe95..e6ad9b44e8fb 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -8101,6 +8101,7 @@ L:linux-ker...@vger.kernel.org
 S: Supported
 T: git git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git
 F: tools/memory-model/
+F: Documentation/memory-barriers.txt
 
 LINUX SECURITY MODULE (LSM) FRAMEWORK
 M: Chris Wright 

--
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 v11 00/10] Application Data Integrity feature introduced by SPARC M7

[Khalid Aziz]

On 02/01/2018 07:29 PM, ebied...@xmission.com wrote:

Khalid Aziz  writes:


V11 changes:
This series is same as v10 and was simply rebased on 4.15 kernel. Can
mm maintainers please review patches 2, 7, 8 and 9 which are arch
independent, and include/linux/mm.h and mm/ksm.c changes in patch 10
and ack these if everything looks good?


I am a bit puzzled how this differs from the pkey's that other
architectures are implementing to achieve a similar result.

I am a bit mystified why you don't store the tag in a vma
instead of inventing a new way to store data on page out.


Hello Eric,

As Steven pointed out, sparc sets tags per cacheline unlike pkey. This 
results in much finer granularity for tags that pkey and hence requires 
larger tag storage than what we can do in a vma.




Can you please use force_sig_fault to send these signals instead
of force_sig_info.  Emperically I have found that it is very
error prone to generate siginfo's by hand, especially on code
paths where several different si_codes may apply.  So it helps
to go through a helper function to ensure the fiddly bits are
all correct.  AKA the unused bits all need to be set to zero before
struct siginfo is copied to userspace.



What you say makes sense. I followed the same code as other fault 
handlers for sparc. I could change just the fault handlers for ADI 
related faults. Would it make more sense to change all the fault 
handlers in a separate patch and keep the code in 
arch/sparc/kernel/traps_64.c consistent? Dave M, do you have a preference?


Thanks,
Khalid
--
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 v11 00/10] Application Data Integrity feature introduced by SPARC M7

[Steven Sistare]

On 2/1/2018 9:29 PM, ebied...@xmission.com wrote:
> Khalid Aziz  writes:
> 
>> V11 changes:
>> This series is same as v10 and was simply rebased on 4.15 kernel. Can
>> mm maintainers please review patches 2, 7, 8 and 9 which are arch
>> independent, and include/linux/mm.h and mm/ksm.c changes in patch 10
>> and ack these if everything looks good?
> 
> I am a bit puzzled how this differs from the pkey's that other
> architectures are implementing to achieve a similar result.
> 
> I am a bit mystified why you don't store the tag in a vma
> instead of inventing a new way to store data on page out.
> 
> Can you please use force_sig_fault to send these signals instead
> of force_sig_info.  Emperically I have found that it is very
> error prone to generate siginfo's by hand, especially on code
> paths where several different si_codes may apply.  So it helps
> to go through a helper function to ensure the fiddly bits are
> all correct.  AKA the unused bits all need to be set to zero before
> struct siginfo is copied to userspace.
> 
> Eric

The ADI tag can be set at a cacheline (64B) granularity, as opposed
to the per-page granularity of pkeys.  This allows an object allocator
to color each object differently within a page (rounding to 64B boundaries),
such that a pointer overrun bug from one object to the next will cause a
fault.  When pages are paged out, the tags must be saved, hence the
new scheme for storing them.  One tag per vma is too coarse.

The combination of fine granularity and pageability makes for a powerful
memory-reference error-detection framework.

This was discussed in more detail when earlier patches were submitted,
but it's been a while, and the distribution was probably narrower.

Khalid can respond to the sig_fault comment.

- Steve
--
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 2/2] MAINTAINERS: list file memory-barriers.txt within the LKMM entry

[Andrea Parri]

Now that a formal specification of the LKMM has become available to
the developer, some concern about how to track changes to the model
on the level of the "high-level documentation" was raised.

A first "mitigation" to this issue, suggested by Will, is to assign
maintainership (and responsibility!!)  of such documentation (here,
memory-barriers.txt) to the maintainers of the LKMM themselves.

Suggested-by: Will Deacon 
Signed-off-by: Andrea Parri 
---
 On top of: https://marc.info/?l=linux-kernel=151748668632046=2 

 MAINTAINERS | 1 +
 1 file changed, 1 insertion(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 08454be9237d7..9466907aa4db1 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -8106,6 +8106,7 @@ L:linux-ker...@vger.kernel.org
 S: Supported
 T: git git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git
 F: tools/memory-model/
+F: Documentation/memory-barriers.txt
 
 LINUX SECURITY MODULE (LSM) FRAMEWORK
 M: Chris Wright 
-- 
2.7.4

--
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 1/2] Documentation/memory-barriers.txt: cross-reference "tools/memory-model/"

[Andrea Parri]

Recent efforts led to the specification of a memory consistency model
for the Linux kernel [1], which "can (roughly speaking) be thought of
as an automated version of memory-barriers.txt" and which is (in turn)
"accompanied by extensive documentation on its use and its design".

Make sure that the (occasional) reader of memory-barriers.txt will be
aware of these developments.

[1] https://marc.info/?l=linux-kernel=151687290114799=2

Signed-off-by: Andrea Parri 
---
 Documentation/memory-barriers.txt | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/Documentation/memory-barriers.txt 
b/Documentation/memory-barriers.txt
index a863009849a3b..8cc3f098f4a7d 100644
--- a/Documentation/memory-barriers.txt
+++ b/Documentation/memory-barriers.txt
@@ -17,7 +17,9 @@ meant as a guide to using the various memory barriers 
provided by Linux, but
 in case of any doubt (and there are many) please ask.
 
 To repeat, this document is not a specification of what Linux expects from
-hardware.
+hardware.  For such a specification, in the form of a memory consistency
+model, and for documentation about its usage and its design, the reader is
+referred to "tools/memory-model/".
 
 The purpose of this document is twofold:
 
-- 
2.7.4

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

[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 ++
>