Groups > linux.kernel > #1235584 > unrolled thread

[PATCH v5 00/23] ILP32 for ARM64

Started by	Yury Norov <ynorov@caviumnetworks.com>
First post	2015-09-30 00:20 +0200
Last post	2015-10-05 21:20 +0200
Articles	17 on this page of 37 — 10 participants

Back to article view | Back to linux.kernel

  [PATCH v5 00/23] ILP32 for ARM64 Yury Norov <ynorov@caviumnetworks.com> - 2015-09-30 00:20 +0200
    [PATCH v5 08/23] arm64:ilp32: use 64bit syscall-names for ILP32 when passing 64bit registers Yury Norov <ynorov@caviumnetworks.com> - 2015-09-30 00:20 +0200
    [PATCH v5 17/23] arm64:ilp32: add vdso-ilp32 and use for signal return Yury Norov <ynorov@caviumnetworks.com> - 2015-09-30 00:20 +0200
      Re: [PATCH v5 17/23] arm64:ilp32: add vdso-ilp32 and use for signal  return Nathan Lynch <Nathan_Lynch@mentor.com> - 2015-09-30 06:10 +0200
        Re: [PATCH v5 17/23] arm64:ilp32: add vdso-ilp32 and use for signal  return Yury Norov <ynorov@caviumnetworks.com> - 2015-10-01 21:50 +0200
          Re: [PATCH v5 17/23] arm64:ilp32: add vdso-ilp32 and use for signal return "Dr. Philipp Tomsich" <philipp.tomsich@theobroma-systems.com> - 2015-10-01 22:40 +0200
    [PATCH v5 09/23] arm64:ilp32: use non-compat syscall names for ILP32 as for LP64 Yury Norov <ynorov@caviumnetworks.com> - 2015-09-30 00:20 +0200
    [PATCH v5 23/23] arm64:ilp32: add ARM64_ILP32 to Kconfig Yury Norov <ynorov@caviumnetworks.com> - 2015-09-30 00:20 +0200
    [PATCH v5 13/23] arm64:ilp32: share HWCAP between LP64 and ILP32 Yury Norov <ynorov@caviumnetworks.com> - 2015-09-30 00:20 +0200
    [PATCH v5 04/23] arm64: change some CONFIG_COMPAT over to use CONFIG_AARCH32_EL0 instead Yury Norov <ynorov@caviumnetworks.com> - 2015-09-30 00:20 +0200
      Re: [PATCH v5 04/23] arm64: change some CONFIG_COMPAT over to use  CONFIG_AARCH32_EL0 instead kbuild test robot <lkp@intel.com> - 2015-09-30 05:40 +0200
    [PATCH v5 02/23] arm64: ensure the kernel is compiled for LP64 Yury Norov <ynorov@caviumnetworks.com> - 2015-09-30 00:20 +0200
    [PATCH v5 16/23] arm64: add support for starting ILP32 (ELFCLASS32) binaries Yury Norov <ynorov@caviumnetworks.com> - 2015-09-30 00:20 +0200
    [PATCH v5 15/23] arm64:ilp32: support core dump generation for ILP32 Yury Norov <ynorov@caviumnetworks.com> - 2015-09-30 00:20 +0200
    [PATCH v5 05/23] arm64:ilp32: expose 'kernel_long' as 'long long' for ILP32 Yury Norov <ynorov@caviumnetworks.com> - 2015-09-30 00:20 +0200
    [PATCH v5 10/23] arm64: introduce is_a32_task and is_a32_thread (for AArch32 compat) Yury Norov <ynorov@caviumnetworks.com> - 2015-09-30 00:20 +0200
      Re: [PATCH v5 10/23] arm64: introduce is_a32_task and is_a32_thread  (for AArch32 compat) kbuild test robot <lkp@intel.com> - 2015-09-30 05:50 +0200
    [PATCH v5 22/23] aarch64: ilp32: msgrcv, msgsnd handlers Yury Norov <ynorov@caviumnetworks.com> - 2015-09-30 00:30 +0200
    [PATCH v5 20/23] arm64:ilp32: use the native siginfo instead of the compat siginfo Yury Norov <ynorov@caviumnetworks.com> - 2015-09-30 00:30 +0200
    [PATCH v5 07/23] arm64:ilp32: share signal structures between ILP32 and LP64 ABIs Yury Norov <ynorov@caviumnetworks.com> - 2015-09-30 00:30 +0200
    [PATCH v5 19/23] arm64:ilp32: add sys_ilp32.c and a separate table (in entry.S) to use it Yury Norov <ynorov@caviumnetworks.com> - 2015-09-30 00:30 +0200
    [PATCH v5 21/23] arm64:ilp32: change COMPAT_ELF_PLATFORM to report a a subplatform for ILP32 Yury Norov <ynorov@caviumnetworks.com> - 2015-09-30 00:30 +0200
    [PATCH v5 18/23] ptrace: Allow compat to use the native siginfo Yury Norov <ynorov@caviumnetworks.com> - 2015-09-30 00:30 +0200
    Re: [PATCH v5 00/23] ILP32 for ARM64 Catalin Marinas <catalin.marinas@arm.com> - 2015-09-30 12:20 +0200
      Re: [PATCH v5 00/23] ILP32 for ARM64 Mark Brown <broonie@kernel.org> - 2015-09-30 18:50 +0200
        Re: [PATCH v5 00/23] ILP32 for ARM64 Catalin Marinas <catalin.marinas@arm.com> - 2015-10-01 13:20 +0200
          Re: [PATCH v5 00/23] ILP32 for ARM64 Mark Brown <broonie@kernel.org> - 2015-10-01 13:40 +0200
            Re: [PATCH v5 00/23] ILP32 for ARM64 Andrey Konovalov <andrey.konovalov@linaro.org> - 2015-10-01 18:50 +0200
        Re: [PATCH v5 00/23] ILP32 for ARM64 Yury Norov <ynorov@caviumnetworks.com> - 2015-10-01 21:40 +0200
      Re: [PATCH v5 00/23] ILP32 for ARM64 Yury Norov <ynorov@caviumnetworks.com> - 2015-10-01 21:20 +0200
        Re: [PATCH v5 00/23] ILP32 for ARM64 Arnd Bergmann <arnd@arndb.de> - 2015-10-01 23:30 +0200
          Re: [PATCH v5 00/23] ILP32 for ARM64 "Pinski, Andrew" <Andrew.Pinski@caviumnetworks.com> - 2015-10-01 23:50 +0200
            Re: [PATCH v5 00/23] ILP32 for ARM64 Catalin Marinas <catalin.marinas@arm.com> - 2015-10-02 11:40 +0200
              Re: [PATCH v5 00/23] ILP32 for ARM64 "Kapoor, Prasun" <Prasun.Kapoor@caviumnetworks.com> - 2015-10-03 05:00 +0200
                Re: [PATCH v5 00/23] ILP32 for ARM64 Catalin Marinas <catalin.marinas@arm.com> - 2015-10-05 18:00 +0200
                  Re: [PATCH v5 00/23] ILP32 for ARM64 "Pinski, Andrew" <Andrew.Pinski@caviumnetworks.com> - 2015-10-05 23:10 +0200
            Re: [PATCH v5 00/23] ILP32 for ARM64 Yury Norov <ynorov@caviumnetworks.com> - 2015-10-05 21:20 +0200

Page 2 of 2 — ← Prev page 1 [2]

#1235603 — [PATCH v5 19/23] arm64:ilp32: add sys_ilp32.c and a separate table (in entry.S) to use it

From	Yury Norov <ynorov@caviumnetworks.com>
Date	2015-09-30 00:30 +0200
Subject	[PATCH v5 19/23] arm64:ilp32: add sys_ilp32.c and a separate table (in entry.S) to use it
Message-ID	<qebzk-2T7-21@gated-at.bofh.it>
In reply to	#1235584

From: Andrew Pinski <apinski@cavium.com>

Add a separate syscall-table for ILP32, which dispatches either to native
LP64 system call implementation or to compat-syscalls, as appropriate.

This revision of the patch now addresses Catalin's comment regarding the
duplicate reading of the task-flags in the el0_svc-handler and simply
relies on the flags having been read by the kernel_entry macro.

Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Signed-off-by: Christoph Muellner <christoph.muellner@theobroma-systems.com>
Signed-off-by: Yury Norov <ynorov@caviumnetworks.com>

 create mode 100644 arch/arm64/kernel/sys_ilp32.c

diff --git a/arch/arm64/include/asm/unistd.h b/arch/arm64/include/asm/unistd.h
index 759c433..31eabf1 100644
--- a/arch/arm64/include/asm/unistd.h
+++ b/arch/arm64/include/asm/unistd.h
@@ -13,6 +13,10 @@
  * You should have received a copy of the GNU General Public License
  * along with this program.  If not, see <http://www.gnu.org/licenses/>.
  */
+#ifdef CONFIG_ARM64_ILP32
+#define __ARCH_WANT_COMPAT_SYS_PREADV64
+#define __ARCH_WANT_COMPAT_SYS_PWRITEV64
+#endif
 #ifdef CONFIG_AARCH32_EL0
 #define __ARCH_WANT_COMPAT_SYS_GETDENTS64
 #define __ARCH_WANT_COMPAT_STAT64
diff --git a/arch/arm64/kernel/Makefile b/arch/arm64/kernel/Makefile
index ff60c2f..a1cbb11 100644
--- a/arch/arm64/kernel/Makefile
+++ b/arch/arm64/kernel/Makefile
@@ -24,6 +24,7 @@ arm64-obj-$(CONFIG_AARCH32_EL0)		+= sys32.o kuser32.o signal32.o 	\
 					   sys_compat.o entry32.o		\
 					   ../../arm/kernel/opcodes.o
 arm64-obj-$(CONFIG_FUNCTION_TRACER)	+= ftrace.o entry-ftrace.o
+arm64-obj-$(CONFIG_ARM64_ILP32)		+= sys_ilp32.o
 arm64-obj-$(CONFIG_MODULES)		+= arm64ksyms.o module.o
 arm64-obj-$(CONFIG_PERF_EVENTS)		+= perf_regs.o perf_callchain.o
 arm64-obj-$(CONFIG_HW_PERF_EVENTS)	+= perf_event.o
diff --git a/arch/arm64/kernel/entry.S b/arch/arm64/kernel/entry.S
index 52be5c8..bcd921a 100644
--- a/arch/arm64/kernel/entry.S
+++ b/arch/arm64/kernel/entry.S
@@ -664,9 +664,13 @@ ENDPROC(ret_from_fork)
  */
 	.align	6
 el0_svc:
-	adrp	stbl, sys_call_table		// load syscall table pointer
 	uxtw	scno, w8			// syscall number in w8
 	mov	sc_nr, #__NR_syscalls
+#ifdef CONFIG_ARM64_ILP32
+	ldr	x16, [tsk, #TI_FLAGS]
+	tbnz	x16, #TIF_32BIT_AARCH64, el0_ilp32_svc // We are using ILP32
+#endif
+	adrp	stbl, sys_call_table		// load syscall table pointer
 el0_svc_naked:					// compat entry point
 	stp	x0, scno, [sp, #S_ORIG_X0]	// save the original x0 and syscall number
 	enable_dbg_and_irq
@@ -686,6 +690,12 @@ ni_sys:
 	b	ret_fast_syscall
 ENDPROC(el0_svc)
 
+#ifdef CONFIG_ARM64_ILP32
+el0_ilp32_svc:
+	adrp	stbl, sys_call_ilp32_table // load syscall table pointer
+	b el0_svc_naked
+#endif
+
 	/*
 	 * This is the really slow path.  We're going to be doing context
 	 * switches, and waiting for our parent to respond.
diff --git a/arch/arm64/kernel/sys_ilp32.c b/arch/arm64/kernel/sys_ilp32.c
new file mode 100644
index 0000000..623191a
--- /dev/null
+++ b/arch/arm64/kernel/sys_ilp32.c
@@ -0,0 +1,178 @@
+/*
+ * AArch64- ILP32 specific system calls implementation
+ *
+ * Copyright (C) 2013 Cavium Inc.
+ * Author: Andrew Pinski <apinski@cavium.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see <http://www.gnu.org/licenses/>.
+ */
+
+#include <linux/compiler.h>
+#include <linux/errno.h>
+#include <linux/fs.h>
+#include <linux/mm.h>
+#include <linux/export.h>
+#include <linux/sched.h>
+#include <linux/slab.h>
+#include <linux/syscalls.h>
+#include <linux/compat.h>
+
+/*
+ * Wrappers to pass the pt_regs argument.
+ */
+asmlinkage long sys_rt_sigreturn_wrapper(void);
+#define sys_rt_sigreturn        sys_rt_sigreturn_wrapper
+
+/* Using Compat syscalls where necessary */
+#define sys_ioctl		compat_sys_ioctl
+/* iovec */
+#define sys_readv		compat_sys_readv
+#define sys_writev		compat_sys_writev
+#define sys_preadv		compat_sys_preadv64
+#define sys_pwritev		compat_sys_pwritev64
+#define sys_vmsplice		compat_sys_vmsplice
+/* robust_list_head */
+#define sys_set_robust_list	compat_sys_set_robust_list
+#define sys_get_robust_list	compat_sys_get_robust_list
+
+/* kexec_segment */
+#define sys_kexec_load		compat_sys_kexec_load
+
+/* Ptrace has some structures which are different between ILP32 and LP64 */
+#define sys_ptrace		compat_sys_ptrace
+
+/* struct msghdr */
+#define sys_recvfrom		compat_sys_recvfrom
+#define sys_recvmmsg		compat_sys_recvmmsg
+#define sys_sendmmsg		compat_sys_sendmmsg
+#define sys_sendmsg		compat_sys_sendmsg
+#define sys_recvmsg		compat_sys_recvmsg
+
+#define sys_setsockopt		compat_sys_setsockopt
+#define sys_getsockopt		compat_sys_getsockopt
+
+/* Array of pointers */
+#define sys_execve		compat_sys_execve
+#define sys_move_pages		compat_sys_move_pages
+
+/* iovec */
+#define sys_process_vm_readv	compat_sys_process_vm_readv
+#define sys_process_vm_writev	compat_sys_process_vm_writev
+
+/* Pointer in struct */
+#define sys_mount               compat_sys_mount
+
+/* NUMA */
+/* unsigned long bitmaps */
+#define sys_get_mempolicy       compat_sys_get_mempolicy
+#define sys_set_mempolicy       compat_sys_set_mempolicy
+#define sys_mbind               compat_sys_mbind
+/* array of pointers */
+/* unsigned long bitmaps */
+#define sys_migrate_pages       compat_sys_migrate_pages
+
+/* Scheduler */
+/* unsigned long bitmaps */
+#define sys_sched_setaffinity   compat_sys_sched_setaffinity
+#define sys_sched_getaffinity   compat_sys_sched_getaffinity
+
+/* iov usage */
+#define sys_keyctl              compat_sys_keyctl
+
+/* aio */
+/* Pointer to Pointer  */
+#define sys_io_setup		compat_sys_io_setup
+/* Array of pointers */
+#define sys_io_submit           compat_sys_io_submit
+
+/* We need to make sure the pointer gets copied correctly. */
+asmlinkage long ilp32_sys_mq_notify(mqd_t mqdes, const struct sigevent __user *u_notification)
+{
+	struct sigevent __user *p = NULL;
+	if (u_notification) {
+		struct sigevent n;
+		p = compat_alloc_user_space(sizeof(*p));
+		if (copy_from_user(&n, u_notification, sizeof(*p)))
+			return -EFAULT;
+		if (n.sigev_notify == SIGEV_THREAD)
+			n.sigev_value.sival_ptr = compat_ptr((uintptr_t)n.sigev_value.sival_ptr);
+		if (copy_to_user(p, &n, sizeof(*p)))
+			return -EFAULT;
+	}
+	return sys_mq_notify(mqdes, p);
+}
+
+/* sigevent contains sigval_t which is now 64bit always
+   but need special handling due to padding for SIGEV_THREAD.  */
+#define sys_mq_notify		ilp32_sys_mq_notify
+
+
+/* sigaltstack needs some special handling as the
+   padding for stack_t might not be non-zero. */
+long ilp32_sys_sigaltstack(const stack_t __user *uss_ptr,
+			   stack_t __user *uoss_ptr)
+{
+	stack_t uss, uoss;
+	int ret;
+	mm_segment_t seg;
+
+	if (uss_ptr) {
+		if (!access_ok(VERIFY_READ, uss_ptr, sizeof(*uss_ptr)))
+			return -EFAULT;
+		if (__get_user(uss.ss_sp, &uss_ptr->ss_sp) |
+			__get_user(uss.ss_flags, &uss_ptr->ss_flags) |
+			__get_user(uss.ss_size, &uss_ptr->ss_size))
+			return -EFAULT;
+		/* Zero extend the sp address and the size. */
+		uss.ss_sp = (void *)(uintptr_t)(unsigned int)(uintptr_t)uss.ss_sp;
+		uss.ss_size = (size_t)(unsigned int)uss.ss_size;
+	}
+	seg = get_fs();
+	set_fs(KERNEL_DS);
+	/* Note we need to use uoss as we have changed the segment to the
+	   kernel one so passing an user one around is wrong. */
+	ret = sys_sigaltstack((stack_t __force __user *) (uss_ptr ? &uss : NULL),
+			      (stack_t __force __user *) &uoss);
+	set_fs(seg);
+	if (ret >= 0 && uoss_ptr)  {
+		if (!access_ok(VERIFY_WRITE, uoss_ptr, sizeof(stack_t)) ||
+		    __put_user(uoss.ss_sp, &uoss_ptr->ss_sp) ||
+		    __put_user(uoss.ss_flags, &uoss_ptr->ss_flags) ||
+		    __put_user(uoss.ss_size, &uoss_ptr->ss_size))
+			ret = -EFAULT;
+	}
+	return ret;
+}
+
+/* sigaltstack needs some special handling as the padding
+   for stack_t might not be non-zero. */
+#define sys_sigaltstack		ilp32_sys_sigaltstack
+
+
+#include <asm/syscall.h>
+
+#undef __SYSCALL
+#define __SYSCALL(nr, sym)	[nr] = sym,
+
+asmlinkage long sys_mmap(unsigned long addr, unsigned long len,
+			 unsigned long prot, unsigned long flags,
+			 unsigned long fd, off_t off);
+
+/*
+ * The sys_call_ilp32_table array must be 4K aligned to be accessible from
+ * kernel/entry.S.
+ */
+void *sys_call_ilp32_table[__NR_syscalls] __aligned(4096) = {
+	[0 ... __NR_syscalls - 1] = sys_ni_syscall,
+#include <asm/unistd.h>
+};
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1235604 — [PATCH v5 21/23] arm64:ilp32: change COMPAT_ELF_PLATFORM to report a a subplatform for ILP32

From	Yury Norov <ynorov@caviumnetworks.com>
Date	2015-09-30 00:30 +0200
Subject	[PATCH v5 21/23] arm64:ilp32: change COMPAT_ELF_PLATFORM to report a a subplatform for ILP32
Message-ID	<qebzk-2T7-23@gated-at.bofh.it>
In reply to	#1235584

From: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>

To make life for tools (such as gdb) easier when dealing with ILP32 processes,
we report a proper subarchitecture for ILP32 in the ELF auxiliary vectors.

Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Signed-off-by: Christoph Muellner <christoph.muellner@theobroma-systems.com>
Signed-off-by: Yury Norov <ynorov@caviumnetworks.com>

diff --git a/arch/arm64/include/asm/elf.h b/arch/arm64/include/asm/elf.h
index 9a854f9..8ef8fc5 100644
--- a/arch/arm64/include/asm/elf.h
+++ b/arch/arm64/include/asm/elf.h
@@ -163,9 +163,9 @@ extern int arch_setup_additional_pages(struct linux_binprm *bprm,
 #ifdef CONFIG_COMPAT
 
 #ifdef __AARCH64EB__
-#define COMPAT_ELF_PLATFORM		("v8b")
+#define COMPAT_ELF_PLATFORM		(is_ilp32_compat_task() ? "aarch64_be:ilp32" : "v8b")
 #else
-#define COMPAT_ELF_PLATFORM		("v8l")
+#define COMPAT_ELF_PLATFORM		(is_ilp32_compat_task() ? "aarch64:ilp32" : "v8l")
 #endif
 
 #define COMPAT_ELF_ET_DYN_BASE		(2 * TASK_SIZE_32 / 3)
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1235605 — [PATCH v5 18/23] ptrace: Allow compat to use the native siginfo

From	Yury Norov <ynorov@caviumnetworks.com>
Date	2015-09-30 00:30 +0200
Subject	[PATCH v5 18/23] ptrace: Allow compat to use the native siginfo
Message-ID	<qebzk-2T7-13@gated-at.bofh.it>
In reply to	#1235584

From: Andrew Pinski <apinski@cavium.com>

Set COMPAT_USE_NATIVE_SIGINFO to be true for non AARCH32 tasks.

With ARM64 ILP32 ABI, we want to use the non-compat
siginfo as we want to simplify signal handling for this new ABI.
This patch just adds a new define COMPAT_USE_NATIVE_SIGINFO and
if it is true then read/write in the compat case as it was the
non-compat case.

Signed-off-by: Christoph Muellner <christoph.muellner@theobroma-systems.com>
Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Signed-off-by: Yury Norov <ynorov@caviumnetworks.com>

diff --git a/include/linux/compat.h b/include/linux/compat.h
index a76c917..0a25d90 100644
--- a/include/linux/compat.h
+++ b/include/linux/compat.h
@@ -24,6 +24,10 @@
 #define COMPAT_USE_64BIT_TIME 0
 #endif
 
+#ifndef COMPAT_USE_NATIVE_SIGINFO
+#define COMPAT_USE_NATIVE_SIGINFO 0
+#endif
+
 #ifndef __SC_DELOUSE
 #define __SC_DELOUSE(t,v) ((t)(unsigned long)(v))
 #endif
diff --git a/kernel/ptrace.c b/kernel/ptrace.c
index 787320d..04799aa 100644
--- a/kernel/ptrace.c
+++ b/kernel/ptrace.c
@@ -652,7 +652,7 @@ static int ptrace_peek_siginfo(struct task_struct *child,
 			break;
 
 #ifdef CONFIG_COMPAT
-		if (unlikely(is_compat_task())) {
+		if (unlikely(is_compat_task() && !COMPAT_USE_NATIVE_SIGINFO)) {
 			compat_siginfo_t __user *uinfo = compat_ptr(data);
 
 			if (copy_siginfo_to_user32(uinfo, &info) ||
@@ -1140,16 +1140,26 @@ int compat_ptrace_request(struct task_struct *child, compat_long_t request,
 
 	case PTRACE_GETSIGINFO:
 		ret = ptrace_getsiginfo(child, &siginfo);
-		if (!ret)
-			ret = copy_siginfo_to_user32(
-				(struct compat_siginfo __user *) datap,
-				&siginfo);
+		if (!ret) {
+			if (COMPAT_USE_NATIVE_SIGINFO)
+				ret = copy_siginfo_to_user(
+					(struct siginfo __user *) datap,
+					&siginfo);
+			else
+				ret = copy_siginfo_to_user32(
+					(struct compat_siginfo __user *) datap,
+					&siginfo);
+		}
 		break;
 
 	case PTRACE_SETSIGINFO:
 		memset(&siginfo, 0, sizeof siginfo);
-		if (copy_siginfo_from_user32(
-			    &siginfo, (struct compat_siginfo __user *) datap))
+		if (COMPAT_USE_NATIVE_SIGINFO)
+			ret = copy_from_user(&siginfo, datap, sizeof(siginfo));
+		else
+			ret = copy_siginfo_from_user32(
+				 &siginfo, (struct compat_siginfo __user *) datap);
+		if (ret)
 			ret = -EFAULT;
 		else
 			ret = ptrace_setsiginfo(child, &siginfo);
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1236049

From	Catalin Marinas <catalin.marinas@arm.com>
Date	2015-09-30 12:20 +0200
Message-ID	<qemEv-1ZQ-69@gated-at.bofh.it>
In reply to	#1235584

On Wed, Sep 30, 2015 at 01:13:57AM +0300, Yury Norov wrote:
> V5 reincarnation for ILP32.
> 
> This is mostly the same code as Andrew suggested in v3:
> 	https://lkml.org/lkml/2014/9/3/704.
> 
> V4 series and discussion:
> 	https://lkml.org/lkml/2015/4/13/691
> 
> Discussion on v3 and v4 raised questions and some disagreement in community,
> and therefore patches are not accepted till now. In this v5 I tried to avoid any
> changes that are not about obvious fixes, so all interface and implementation
> questions are still here.

This thing comes roughly every 5-6 months, so I don't think it's worth
reviewing it again and forgetting about it until sometime next year. We
also had discussions on the v4 and IIRC we agreed that the ABI should be
closer to AArch32/compat in terms of __kernel_size_t, time_t but with
the canonical set of system calls from the asm-generic/unistd.h.

> In v5:
>  - rebased on top of 4.3.0-rc3;
>  - build fixed if ILP32 enabled without AARCH32;
>  - PATCH v4 22/24 (use compat for stack_t) dropped because it confuses
>    debug tools like gdb and strace;
>  - PATCH v4 20/24 (use compat-syscalls for msgsnd and msgrcv for ILP32)
>    dropped as breaking tests;
>  - PATCH v5 22/23 (msgrcv, msgsnd handlers) introduced for proper 
>    handling of msgrcv, msgsnd;
>  - other minor fixes.

So apart from rebasing, there are no ABI changes. I don't think it's
worth re-discussing the points raised during v4.

> Questions under discussion:
>  - What for ILP32 on ARM64?
> 	See https://lkml.org/lkml/2015/4/13/814
> 	and http://permalink.gmane.org/gmane.comp.lib.uclibc.buildroot/121100
> 	Briefly,
> 	 - for compatibility;
> 	 - for performance;
> 	 - for memory saving.

Does anyone actually need this ABI? And by "need" I don't mean a
tick-box on product fliers but actually someone going to use it on real
systems in the field. Because I'm not keen on maintaining an ABI in the
kernel just as a PR exercise. I have yet to see conclusive benchmarks
that ILP32 is a real win vs LP64 but happy to be proven wrong.

That said, I'm fine with agreeing on an ABI and see whether it takes off
before any merging decisions.

>  - ABI questions: time_t and so on;
> 	I think we are out of choice now. Patches to GCC and Glibc are
> 	upstreamed more than a year ago, and there already might be a code compiled
> 	against existing ABI. At the end, there is no major disagreement, and final
> 	word is after ABI users. And I found no objections from that side.

CORRECTION: patches for gcc have been upstreamed, that's the ELF and PCS
AArch64 ILP32 ABI. The syscall ABI which goes in glibc hasn't been
merged because we did not reach an agreement on the kernel ABI (it would
be rather silly to push something into mainline glibc that's not
officially supported by Linux).

I really don't care if there is compiled code out there using out of
tree patches for glibc and the kernel.

>  - Implementation questions: use ILP32 separated table or not, and others;
> 	Code proposed by Andrew works just fine for more than a year,
> 	and it even shows slightly better performance comparing to LP64:
> 	http://permalink.gmane.org/gmane.comp.lib.uclibc.buildroot/121100
> 	So I see no reason to change something except obvious bugs, if found.

As I said, with patches twice a year, I don't remember the past
discussions. So normally you should start with v4 and address the
comments there. But you seem to have refreshed v3.

Anyway, if by table you mean the syscall table, I think on v4 we agreed
on a separate ILP32 syscall table using the generic syscall numbering
but with some compat syscall pointers where applicable.

-- 
Catalin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1236527

From	Mark Brown <broonie@kernel.org>
Date	2015-09-30 18:50 +0200
Message-ID	<qesJP-2eW-1@gated-at.bofh.it>
In reply to	#1236049

[Multipart message — attachments visible in raw view] — view raw

On Wed, Sep 30, 2015 at 11:19:19AM +0100, Catalin Marinas wrote:
> On Wed, Sep 30, 2015 at 01:13:57AM +0300, Yury Norov wrote:

> >  - What for ILP32 on ARM64?
> > 	See https://lkml.org/lkml/2015/4/13/814
> > 	and http://permalink.gmane.org/gmane.comp.lib.uclibc.buildroot/121100
> > 	Briefly,
> > 	 - for compatibility;
> > 	 - for performance;
> > 	 - for memory saving.

> Does anyone actually need this ABI? And by "need" I don't mean a
> tick-box on product fliers but actually someone going to use it on real
> systems in the field. Because I'm not keen on maintaining an ABI in the
> kernel just as a PR exercise. I have yet to see conclusive benchmarks
> that ILP32 is a real win vs LP64 but happy to be proven wrong.

Indeed.  On that subject there was some discussion at Linaro Connect
last week about work (being done outside Linaro, not sure how public it
is at this point) to pull together the current state of the art into a
Docker container image which people can use for benchmarking and as a
reference for how to pull things together.  That should help with the
analysis, it'll at least make it easier for other people to reproduce
any benchmarking results.

[toc] | [prev] | [next] | [standalone]

#1237278

From	Catalin Marinas <catalin.marinas@arm.com>
Date	2015-10-01 13:20 +0200
Message-ID	<qeK42-2oH-9@gated-at.bofh.it>
In reply to	#1236527

On Wed, Sep 30, 2015 at 05:41:03PM +0100, Mark Brown wrote:
> On Wed, Sep 30, 2015 at 11:19:19AM +0100, Catalin Marinas wrote:
> > On Wed, Sep 30, 2015 at 01:13:57AM +0300, Yury Norov wrote:
> 
> > >  - What for ILP32 on ARM64?
> > > 	See https://lkml.org/lkml/2015/4/13/814
> > > 	and http://permalink.gmane.org/gmane.comp.lib.uclibc.buildroot/121100
> > > 	Briefly,
> > > 	 - for compatibility;
> > > 	 - for performance;
> > > 	 - for memory saving.
> 
> > Does anyone actually need this ABI? And by "need" I don't mean a
> > tick-box on product fliers but actually someone going to use it on real
> > systems in the field. Because I'm not keen on maintaining an ABI in the
> > kernel just as a PR exercise. I have yet to see conclusive benchmarks
> > that ILP32 is a real win vs LP64 but happy to be proven wrong.
> 
> Indeed.  On that subject there was some discussion at Linaro Connect
> last week about work (being done outside Linaro, not sure how public it
> is at this point) to pull together the current state of the art into a
> Docker container image which people can use for benchmarking and as a
> reference for how to pull things together.  That should help with the
> analysis, it'll at least make it easier for other people to reproduce
> any benchmarking results.

That's fine and I would welcome it. However, I'm definitely against
using non-agreed ABI and further spreading such toolchains (or kernel
patches; Linaro's tracking kernel has kept these patches for a long
time, even though the ABI has been NAK'ed).

-- 
Catalin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1237294

From	Mark Brown <broonie@kernel.org>
Date	2015-10-01 13:40 +0200
Message-ID	<qeKno-2Lo-9@gated-at.bofh.it>
In reply to	#1237278

[Multipart message — attachments visible in raw view] — view raw

On Thu, Oct 01, 2015 at 12:19:31PM +0100, Catalin Marinas wrote:
> On Wed, Sep 30, 2015 at 05:41:03PM +0100, Mark Brown wrote:

> > Indeed.  On that subject there was some discussion at Linaro Connect
> > last week about work (being done outside Linaro, not sure how public it
> > is at this point) to pull together the current state of the art into a
> > Docker container image which people can use for benchmarking and as a
> > reference for how to pull things together.  That should help with the
> > analysis, it'll at least make it easier for other people to reproduce
> > any benchmarking results.

> That's fine and I would welcome it. However, I'm definitely against
> using non-agreed ABI and further spreading such toolchains (or kernel

You might want to speak to some of your colleagues about that...  in any
case I'll reply off list later today with information on the third party
working on this so you can get in touch, like I say I'm not sure how
public that work is at this point.

> patches; Linaro's tracking kernel has kept these patches for a long
> time, even though the ABI has been NAK'ed).

I know, I'm not thrilled about that either.  :/

[toc] | [prev] | [next] | [standalone]

#1237567

From	Andrey Konovalov <andrey.konovalov@linaro.org>
Date	2015-10-01 18:50 +0200
Message-ID	<qePdo-1O6-9@gated-at.bofh.it>
In reply to	#1237294

On 10/01/2015 02:36 PM, Mark Brown wrote:
> On Thu, Oct 01, 2015 at 12:19:31PM +0100, Catalin Marinas wrote:
>> On Wed, Sep 30, 2015 at 05:41:03PM +0100, Mark Brown wrote:
>
>>> Indeed.  On that subject there was some discussion at Linaro Connect
>>> last week about work (being done outside Linaro, not sure how public it
>>> is at this point) to pull together the current state of the art into a
>>> Docker container image which people can use for benchmarking and as a
>>> reference for how to pull things together.  That should help with the
>>> analysis, it'll at least make it easier for other people to reproduce
>>> any benchmarking results.

Using Docker image sounds like a great idea.

>> That's fine and I would welcome it. However, I'm definitely against
>> using non-agreed ABI and further spreading such toolchains (or kernel
>
> You might want to speak to some of your colleagues about that...  in any
> case I'll reply off list later today with information on the third party
> working on this so you can get in touch, like I say I'm not sure how
> public that work is at this point.
>
>> patches; Linaro's tracking kernel has kept these patches for a long
>> time, even though the ABI has been NAK'ed).
>
> I know, I'm not thrilled about that either.  :/

Same for me.
As you have noticed, ILP32 was removed from Linaro's tracking kernel recently.
The thing is that we (builds&baselines team in Linaro) have been requested
to have a CI loop for ILP32. So I'll continue running it, but will use a
separate git branch for ILP32. The linux-linaro branch will not have ILP32
any more (or at least until ILP32 ABI is agreed on).

Thanks,
Andrey

>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1237685

From	Yury Norov <ynorov@caviumnetworks.com>
Date	2015-10-01 21:40 +0200
Message-ID	<qeRRU-5Ev-19@gated-at.bofh.it>
In reply to	#1236527

On Wed, Sep 30, 2015 at 05:41:03PM +0100, Mark Brown wrote:
> On Wed, Sep 30, 2015 at 11:19:19AM +0100, Catalin Marinas wrote:
> > On Wed, Sep 30, 2015 at 01:13:57AM +0300, Yury Norov wrote:
> 
> > >  - What for ILP32 on ARM64?
> > > 	See https://lkml.org/lkml/2015/4/13/814
> > > 	and http://permalink.gmane.org/gmane.comp.lib.uclibc.buildroot/121100
> > > 	Briefly,
> > > 	 - for compatibility;
> > > 	 - for performance;
> > > 	 - for memory saving.
> 
> > Does anyone actually need this ABI? And by "need" I don't mean a
> > tick-box on product fliers but actually someone going to use it on real
> > systems in the field. Because I'm not keen on maintaining an ABI in the
> > kernel just as a PR exercise. I have yet to see conclusive benchmarks
> > that ILP32 is a real win vs LP64 but happy to be proven wrong.
> 
> Indeed.  On that subject there was some discussion at Linaro Connect
> last week about work (being done outside Linaro, not sure how public it
> is at this point) to pull together the current state of the art into a
> Docker container image which people can use for benchmarking and as a
> reference for how to pull things together.  That should help with the
> analysis, it'll at least make it easier for other people to reproduce
> any benchmarking results.

Hi, Mark,

From you, I got more on what happens with ILP32 than from my company.
Thank you. I know people participated Linaro Connect, and will ask
them for details. And, if possible, will share it here.

BR,
Yury.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1237669

From	Yury Norov <ynorov@caviumnetworks.com>
Date	2015-10-01 21:20 +0200
Message-ID	<qeRyx-5hY-3@gated-at.bofh.it>
In reply to	#1236049

On Wed, Sep 30, 2015 at 11:19:19AM +0100, Catalin Marinas wrote:
> On Wed, Sep 30, 2015 at 01:13:57AM +0300, Yury Norov wrote:
> > V5 reincarnation for ILP32.
> > 
> > This is mostly the same code as Andrew suggested in v3:
> > 	https://lkml.org/lkml/2014/9/3/704.
> > 
> > V4 series and discussion:
> > 	https://lkml.org/lkml/2015/4/13/691
> > 
> > Discussion on v3 and v4 raised questions and some disagreement in community,
> > and therefore patches are not accepted till now. In this v5 I tried to avoid any
> > changes that are not about obvious fixes, so all interface and implementation
> > questions are still here.
> 
> This thing comes roughly every 5-6 months, so I don't think it's worth
> reviewing it again and forgetting about it until sometime next year. We
> also had discussions on the v4 and IIRC we agreed that the ABI should be
> closer to AArch32/compat in terms of __kernel_size_t, time_t but with
> the canonical set of system calls from the asm-generic/unistd.h.
> 
> > In v5:
> >  - rebased on top of 4.3.0-rc3;
> >  - build fixed if ILP32 enabled without AARCH32;
> >  - PATCH v4 22/24 (use compat for stack_t) dropped because it confuses
> >    debug tools like gdb and strace;
> >  - PATCH v4 20/24 (use compat-syscalls for msgsnd and msgrcv for ILP32)
> >    dropped as breaking tests;
> >  - PATCH v5 22/23 (msgrcv, msgsnd handlers) introduced for proper 
> >    handling of msgrcv, msgsnd;
> >  - other minor fixes.
> 
> So apart from rebasing, there are no ABI changes. I don't think it's
> worth re-discussing the points raised during v4.
> 
> > Questions under discussion:
> >  - What for ILP32 on ARM64?
> > 	See https://lkml.org/lkml/2015/4/13/814
> > 	and http://permalink.gmane.org/gmane.comp.lib.uclibc.buildroot/121100
> > 	Briefly,
> > 	 - for compatibility;
> > 	 - for performance;
> > 	 - for memory saving.
> 
> Does anyone actually need this ABI? And by "need" I don't mean a
> tick-box on product fliers but actually someone going to use it on real
> systems in the field. Because I'm not keen on maintaining an ABI in the
> kernel just as a PR exercise. I have yet to see conclusive benchmarks
> that ILP32 is a real win vs LP64 but happy to be proven wrong.
> 

Adding Prasun Capoor <Prasun.Kapoor@caviumnetworks.com>

I'm not familar with details. I know that ARM32 compatibility is the main
concern now. I think, in long run compatibility doesn't mean much.
The performance does instead. Bamvor Jian Zhang reports 10%
performance gain, and I think noone will miss the chance to became 10%
faster, if speed is a real concern, just after rebuilding the application.

> That said, I'm fine with agreeing on an ABI and see whether it takes off
> before any merging decisions.
> 
> >  - ABI questions: time_t and so on;
> > 	I think we are out of choice now. Patches to GCC and Glibc are
> > 	upstreamed more than a year ago, and there already might be a code compiled
> > 	against existing ABI. At the end, there is no major disagreement, and final
> > 	word is after ABI users. And I found no objections from that side.
> 
> CORRECTION: patches for gcc have been upstreamed, that's the ELF and PCS
> AArch64 ILP32 ABI. The syscall ABI which goes in glibc hasn't been
> merged because we did not reach an agreement on the kernel ABI (it would
> be rather silly to push something into mainline glibc that's not
> officially supported by Linux).
> 
> I really don't care if there is compiled code out there using out of
> tree patches for glibc and the kernel.

You right, they are out of tree. Sorry.

> 
> >  - Implementation questions: use ILP32 separated table or not, and others;
> > 	Code proposed by Andrew works just fine for more than a year,
> > 	and it even shows slightly better performance comparing to LP64:
> > 	http://permalink.gmane.org/gmane.comp.lib.uclibc.buildroot/121100
> > 	So I see no reason to change something except obvious bugs, if found.
> 
> As I said, with patches twice a year, I don't remember the past
> discussions. So normally you should start with v4 and address the
> comments there. But you seem to have refreshed v3.
> 
> Anyway, if by table you mean the syscall table, I think on v4 we agreed
> on a separate ILP32 syscall table using the generic syscall numbering
> but with some compat syscall pointers where applicable.
> 

We already have separated ILP32 syscall table, see patch 19 in this
patchset. This is in fact the option e), suggested by Arnd as best
option for him. https://lkml.org/lkml/2015/4/17/237

Regarding time_t, it, of course, doesn't takes much time to make it
32-bit, but I think 64 bit is better because of Y2038. X32 and mips
n32 has time_t 64-bit (and ppc, not sure), and that's OK for them.
That's OK for BSD as well. The objection may come from users of ABI,
complaining portability problems, but I found no such complains in
public discussions.

Nevertheless, as I told, I do not see any problem to rework time_t.
But some arguments supporting this decision are appreciated.

The downside of 32 bit time_t is that we still face Y2038 problem,
but that's the other story fixing it.

__kernel_long_t is the same. Now it's 64 bits length. Compatibility
may suffer, but, again, there're no complains, and in long run it
looks better.

That's what Andrew says, and I'm gonna to agree:
> There are only a few places where long should be 32bit rather than 64bit.
> The non-time_t field of timespec is the only one I can think of. The rest
> are valid and good idea to stay as 64bit. Including the limits.

BR,
Yury

> -- 
> Catalin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1237758

From	Arnd Bergmann <arnd@arndb.de>
Date	2015-10-01 23:30 +0200
Message-ID	<qeTAo-8jY-53@gated-at.bofh.it>
In reply to	#1237669

On Thursday 01 October 2015 22:15:20 Yury Norov wrote:

> Regarding time_t, it, of course, doesn't takes much time to make it
> 32-bit, but I think 64 bit is better because of Y2038. X32 and mips
> n32 has time_t 64-bit (and ppc, not sure), and that's OK for them.

I'm pretty sure that n32 has 32-bit time_t, and we know that it still
causes real-world problems on x32: socket timestamps, v4l, alsa and
other subsystems all have bugs in this area that are hard to fix.

> That's OK for BSD as well. The objection may come from users of ABI,
> complaining portability problems, but I found no such complains in
> public discussions.
>
> Nevertheless, as I told, I do not see any problem to rework time_t.
> But some arguments supporting this decision are appreciated.
> 
> The downside of 32 bit time_t is that we still face Y2038 problem,
> but that's the other story fixing it.

The main reason for 32-bit time_t is compatibility with existing
ioctls (also getsockopts and some others), and having a sane way
for fixing them. We cannot change compat_time_t to be 64-bit
without breaking arm32 compat mode, and we can't use the native
64-bit ioctl implementation on ARM64/ILP32 because that breaks
all interfaces that pass 'long' or a pointer.

This means drivers that currently pass a time_t (or timeval, timespec
etc) need to not only have a compat_ioctl handler to convert it,
they also need to check whether which of the two compat modes they
are talking to. This is a mess to add (I know, because I'm working
on this for y2038 compliance for normal 32-bit mode), and making
the two behave differently makes it even harder to get right for
all cases.

> __kernel_long_t is the same. Now it's 64 bits length. Compatibility
> may suffer, but, again, there're no complains, and in long run it
> looks better.

__kernel_long_t isn't actually used that much, and rarely used in
places where it matters. The idea was to be able to reuse the
native syscalls rather than the compat syscall calls, but that
comes with the downside of defining the ABI in a way that is
incompatible with all other 32-bit user space.

Having a 64-bit __kernel_off_t is similar to the 64-bit time_t:
a good idea in principle, but it breaks device drivers that
expect user space to pass 32-bit arguments. For any interface
that really needs 64-bit data, we have to fix it for all
32-bit architectures, and we're better off avoiding special
cases.

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1237764

From	"Pinski, Andrew" <Andrew.Pinski@caviumnetworks.com>
Date	2015-10-01 23:50 +0200
Message-ID	<qeTTH-eK-11@gated-at.bofh.it>
In reply to	#1237758

> On Oct 1, 2015, at 2:29 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> 
>> On Thursday 01 October 2015 22:15:20 Yury Norov wrote:
>> 
>> Regarding time_t, it, of course, doesn't takes much time to make it
>> 32-bit, but I think 64 bit is better because of Y2038. X32 and mips
>> n32 has time_t 64-bit (and ppc, not sure), and that's OK for them.
> 
> I'm pretty sure that n32 has 32-bit time_t, and we know that it still
> causes real-world problems on x32: socket timestamps, v4l, alsa and
> other subsystems all have bugs in this area that are hard to fix.
> 
>> That's OK for BSD as well. The objection may come from users of ABI,
>> complaining portability problems, but I found no such complains in
>> public discussions.
>> 
>> Nevertheless, as I told, I do not see any problem to rework time_t.
>> But some arguments supporting this decision are appreciated.
>> 
>> The downside of 32 bit time_t is that we still face Y2038 problem,
>> but that's the other story fixing it.
> 
> The main reason for 32-bit time_t is compatibility with existing
> ioctls (also getsockopts and some others), and having a sane way
> for fixing them. We cannot change compat_time_t to be 64-bit
> without breaking arm32 compat mode, and we can't use the native
> 64-bit ioctl implementation on ARM64/ILP32 because that breaks
> all interfaces that pass 'long' or a pointer.
> 
> This means drivers that currently pass a time_t (or timeval, timespec
> etc) need to not only have a compat_ioctl handler to convert it,
> they also need to check whether which of the two compat modes they
> are talking to. This is a mess to add (I know, because I'm working
> on this for y2038 compliance for normal 32-bit mode), and making
> the two behave differently makes it even harder to get right for
> all cases.
> 
>> __kernel_long_t is the same. Now it's 64 bits length. Compatibility
>> may suffer, but, again, there're no complains, and in long run it
>> looks better.
> 
> __kernel_long_t isn't actually used that much, and rarely used in
> places where it matters. The idea was to be able to reuse the
> native syscalls rather than the compat syscall calls, but that
> comes with the downside of defining the ABI in a way that is
> incompatible with all other 32-bit user space.
> 
> Having a 64-bit __kernel_off_t is similar to the 64-bit time_t:
> a good idea in principle, but it breaks device drivers that
> expect user space to pass 32-bit arguments. For any interface
> that really needs 64-bit data, we have to fix it for all
> 32-bit architectures, and we're better off avoiding special
> cases.

Ok, we will rewrite these patches using 32bit time_t and 32bit off_t and redo the toolchain support for them.  Note this is going back to the abi I had originally done when I submitted my original version when it was asked to change time_t to be 64bit. 

Thanks,
Andrew


> 
>    Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1238065

From	Catalin Marinas <catalin.marinas@arm.com>
Date	2015-10-02 11:40 +0200
Message-ID	<qf4YN-7RN-1@gated-at.bofh.it>
In reply to	#1237764

On Thu, Oct 01, 2015 at 09:49:46PM +0000, Pinski, Andrew wrote:
> Ok, we will rewrite these patches using 32bit time_t and 32bit off_t
> and redo the toolchain support for them.  Note this is going back to
> the abi I had originally done when I submitted my original version
> when it was asked to change time_t to be 64bit. 

One of the key aspects of kernel development is the ability to adapt
quickly to new requests/insights. This implies releasing early and often
rather than a new version roughly twice a year (IIRC, v1 was posted
September 2013). Moreover, the success of the kernel is partly based on
not getting stuck on old decisions (well, unless it breaks accepted user
ABI).

So, at the time, following x32 discussions, we thought of using the
native ABI as much as possible. However, two important things happened
since:

1. libc community didn't like breaking the POSIX compliance
2. No-one seems desperate for ILP32 on AArch64

(1) is a fair point and I would rather be careful as we don't know the
extent of the code affected. In the meantime, we've also had ongoing
work for addressing the 2038 issue on 32-bit architectures.

The second point is equally important. The benchmarks I've seen didn't
show a significant improvement and the messages I got on various
channels pretty much labeled ILP32 as a transitional stage to full LP64.
In this case, we need to balance the benefits of a close to native ABI
(future proof, slightly higher performance) vs. the cost of maintaining
such ABI in the kernel on the long term, especially if it's not widely
used/tested.

We've seen the kernel patches and, following discussions on the lists,
decided to change the original recommendation. IIRC, the main ideas (but
you need to read various threads as I can't remember the details from
6-7 months ago):

a) separate syscall table for ILP32
b) close to compat ABI with 32-bit time_t, off_t
c) asm-generic/unistd.h rather than asm/unistd32.h (that's where it
   would differ from compat, together with places where pointers are
   passed)

As I said previously, I'm not going to pay any attention to the patches
in this series, it's nothing more than a rebase of a version I already
reviewed.

-- 
Catalin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1238722

From	"Kapoor, Prasun" <Prasun.Kapoor@caviumnetworks.com>
Date	2015-10-03 05:00 +0200
Message-ID	<qfldf-5Mk-1@gated-at.bofh.it>
In reply to	#1238065


On 10/2/15, 2:37 AM, "Catalin Marinas" <catalin.marinas@arm.com> wrote:

>On Thu, Oct 01, 2015 at 09:49:46PM +0000, Pinski, Andrew wrote:
>> Ok, we will rewrite these patches using 32bit time_t and 32bit off_t
>> and redo the toolchain support for them.  Note this is going back to
>> the abi I had originally done when I submitted my original version
>> when it was asked to change time_t to be 64bit.
>
>One of the key aspects of kernel development is the ability to adapt
>quickly to new requests/insights. This implies releasing early and often
>rather than a new version roughly twice a year (IIRC, v1 was posted
>September 2013). Moreover, the success of the kernel is partly based on
>not getting stuck on old decisions (well, unless it breaks accepted user
>ABI).
>
>So, at the time, following x32 discussions, we thought of using the
>native ABI as much as possible. However, two important things happened
>since:
>
>1. libc community didn't like breaking the POSIX compliance
>2. No-one seems desperate for ILP32 on AArch64
>
>(1) is a fair point and I would rather be careful as we don't know the
>extent of the code affected. In the meantime, we've also had ongoing
>work for addressing the 2038 issue on 32-bit architectures.
>
>The second point is equally important. The benchmarks I've seen didn't
>show a significant improvement and the messages I got on various
>channels pretty much labeled ILP32 as a transitional stage to full LP64.
>In this case, we need to balance the benefits of a close to native ABI
>(future proof, slightly higher performance) vs. the cost of maintaining
>such ABI in the kernel on the long term, especially if it's not widely
>used/tested.


For us ILP32  is not about putting this into our product flier at all, it
is about supporting real applications. We have an existing product line of
MIPS based SoCs where a large number of N32 (an exact equivalent of ILP32)
applications are currently in production. Our customers are looking to
bring those applications (mostly in Networking and Telecom space) over to
ARMv8. 

We think its an extremely risky strategy to say either future processors
should incur the additional cost (power and complexity) of implementing
Aarch32 instruction set or have no way of  supporting 32 bit applications
at all.

Apart from there being an installed base of 32 bit networking and telecom
applications, we have also seen non-trivial performance gains with ILP32
(for example, our SPECINT score goes up by 7% with ILP32 compared to
LP64).  



>
>We've seen the kernel patches and, following discussions on the lists,
>decided to change the original recommendation. IIRC, the main ideas (but
>you need to read various threads as I can't remember the details from
>6-7 months ago):
>
>a) separate syscall table for ILP32
>b) close to compat ABI with 32-bit time_t, off_t
>c) asm-generic/unistd.h rather than asm/unistd32.h (that's where it
>   would differ from compat, together with places where pointers are
>   passed)
>
>As I said previously, I'm not going to pay any attention to the patches
>in this series, it's nothing more than a rebase of a version I already
>reviewed.
>
>-- 
>Catalin

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1239696

From	Catalin Marinas <catalin.marinas@arm.com>
Date	2015-10-05 18:00 +0200
Message-ID	<qgglc-3nE-13@gated-at.bofh.it>
In reply to	#1238722

On Sat, Oct 03, 2015 at 02:18:57AM +0000, Kapoor, Prasun wrote:
> On 10/2/15, 2:37 AM, "Catalin Marinas" <catalin.marinas@arm.com> wrote:
> >So, at the time, following x32 discussions, we thought of using the
> >native ABI as much as possible. However, two important things happened
> >since:
> >
> >1. libc community didn't like breaking the POSIX compliance
> >2. No-one seems desperate for ILP32 on AArch64
> >
> >(1) is a fair point and I would rather be careful as we don't know the
> >extent of the code affected. In the meantime, we've also had ongoing
> >work for addressing the 2038 issue on 32-bit architectures.
> >
> >The second point is equally important. The benchmarks I've seen didn't
> >show a significant improvement and the messages I got on various
> >channels pretty much labeled ILP32 as a transitional stage to full LP64.
> >In this case, we need to balance the benefits of a close to native ABI
> >(future proof, slightly higher performance) vs. the cost of maintaining
> >such ABI in the kernel on the long term, especially if it's not widely
> >used/tested.
> 
> For us ILP32  is not about putting this into our product flier at all, it
> is about supporting real applications. We have an existing product line of
> MIPS based SoCs where a large number of N32 (an exact equivalent of ILP32)
> applications are currently in production. Our customers are looking to
> bring those applications (mostly in Networking and Telecom space) over to
> ARMv8. 
> 
> We think its an extremely risky strategy to say either future processors
> should incur the additional cost (power and complexity) of implementing
> Aarch32 instruction set or have no way of  supporting 32 bit applications
> at all.

Well, given that Cavium posted only 3 versions of this series since
September 2013, it doesn't seem critical at all.

> Apart from there being an installed base of 32 bit networking and telecom
> applications, we have also seen non-trivial performance gains with ILP32
> (for example, our SPECINT score goes up by 7% with ILP32 compared to
> LP64).

It would be good to re-run the benchmarks with the latest gcc since
LP64/AArch64 support has evolved in the meantime.

-- 
Catalin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1239965

From	"Pinski, Andrew" <Andrew.Pinski@caviumnetworks.com>
Date	2015-10-05 23:10 +0200
Message-ID	<qglbc-2cb-31@gated-at.bofh.it>
In reply to	#1239696


> On Oct 5, 2015, at 8:59 AM, Catalin Marinas <catalin.marinas@arm.com> wrote:
> 
>> On Sat, Oct 03, 2015 at 02:18:57AM +0000, Kapoor, Prasun wrote:
>>> On 10/2/15, 2:37 AM, "Catalin Marinas" <catalin.marinas@arm.com> wrote:
>>> So, at the time, following x32 discussions, we thought of using the
>>> native ABI as much as possible. However, two important things happened
>>> since:
>>> 
>>> 1. libc community didn't like breaking the POSIX compliance
>>> 2. No-one seems desperate for ILP32 on AArch64
>>> 
>>> (1) is a fair point and I would rather be careful as we don't know the
>>> extent of the code affected. In the meantime, we've also had ongoing
>>> work for addressing the 2038 issue on 32-bit architectures.
>>> 
>>> The second point is equally important. The benchmarks I've seen didn't
>>> show a significant improvement and the messages I got on various
>>> channels pretty much labeled ILP32 as a transitional stage to full LP64.
>>> In this case, we need to balance the benefits of a close to native ABI
>>> (future proof, slightly higher performance) vs. the cost of maintaining
>>> such ABI in the kernel on the long term, especially if it's not widely
>>> used/tested.
>> 
>> For us ILP32  is not about putting this into our product flier at all, it
>> is about supporting real applications. We have an existing product line of
>> MIPS based SoCs where a large number of N32 (an exact equivalent of ILP32)
>> applications are currently in production. Our customers are looking to
>> bring those applications (mostly in Networking and Telecom space) over to
>> ARMv8. 
>> 
>> We think its an extremely risky strategy to say either future processors
>> should incur the additional cost (power and complexity) of implementing
>> Aarch32 instruction set or have no way of  supporting 32 bit applications
>> at all.
> 
> Well, given that Cavium posted only 3 versions of this series since
> September 2013, it doesn't seem critical at all.

We are going to post another version as soon as we finish the changes that you requested this time around. I am working on the glibc and yury (with my help) will doing the kernel side. 


> 
>> Apart from there being an installed base of 32 bit networking and telecom
>> applications, we have also seen non-trivial performance gains with ILP32
>> (for example, our SPECINT score goes up by 7% with ILP32 compared to
>> LP64).
> 
> It would be good to re-run the benchmarks with the latest gcc since
> LP64/AArch64 support has evolved in the meantime.

We are also rerunning the numbers with the latest released gcc (5.2) and will report results when we submit the next version of the patch set.  

Thanks,
Andrew

> 
> -- 
> Catalin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1239855

From	Yury Norov <ynorov@caviumnetworks.com>
Date	2015-10-05 21:20 +0200
Message-ID	<qgjsJ-821-7@gated-at.bofh.it>
In reply to	#1237764

On Fri, Oct 02, 2015 at 12:49:46AM +0300, Pinski, Andrew wrote:

[...]

> Ok, we will rewrite these patches using 32bit time_t and 32bit off_t and
> redo the toolchain support for them.  Note this is going back to the abi
> I had originally done when I submitted my original version when it was
> asked to change time_t to be 64bit. 
> 
> Thanks,
> Andrew

Hi Andrew,

I try to apply your glibc ILP32 patchset on current glibc master, but
there're many merge failures.
        https://sourceware.org/ml/libc-alpha/2014-10/msg00596.html

Could you share more fresh version of it, if you have one?

Are there any special commands or configure options needed 
to enable ILP32 properly?

BR,
Yury.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

csiph-web

[PATCH v5 00/23] ILP32 for ARM64

Contents

#1235603 — [PATCH v5 19/23] arm64:ilp32: add sys_ilp32.c and a separate table (in entry.S) to use it

#1235604 — [PATCH v5 21/23] arm64:ilp32: change COMPAT_ELF_PLATFORM to report a a subplatform for ILP32

#1235605 — [PATCH v5 18/23] ptrace: Allow compat to use the native siginfo

#1236049

#1236527

#1237278

#1237294

#1237567

#1237685

#1237669

#1237758

#1237764

#1238065

#1238722

#1239696

#1239965

#1239855