WTF: patch "[PATCH] ARC: Support syscall ABI v4" was seriously submitted to be applied to the 4.7-stable tree?

From 840c054fd0efb048df6fceb0c46385ec5b66dfe6 Mon Sep 17 00:00:00 2001

The patch below was submitted to be applied to the 4.7-stable tree.

I fail to see how this patch meets the stable kernel rules as found at Documentation/stable_kernel_rules.txt.

I could be totally wrong, and if so, please respond to <[email protected]> and let me know why this patch should be applied. Otherwise, it is now dropped from my patch queues, never to be seen again.

thanks,

greg k-h

------------------ original commit in Linus's tree ------------------

From 840c054fd0efb048df6fceb0c46385ec5b66dfe6 Mon Sep 17 00:00:00 2001
From: Vineet Gupta <[email protected]>
Date: Wed, 10 Aug 2016 14:10:57 -0700
Subject: [PATCH] ARC: Support syscall ABI v4

The syscall ABI includes the gcc functional calling ABI since a syscall implies userland caller and kernel callee.

The current gcc ABI (v3) for ARCv2 ISA required 64-bit data be passed in even-odd register pairs, (potentially punching reg holes when passing such values as args). This was partly driven by the fact that the double-word LDD/STD instructions in ARCv2 expect the register alignment and thus gcc forcing this avoids extra MOV at the cost of a few unused register (which we have plenty anyways).

This however was rejected as part of upstreaming gcc port to HS. So the new ABI v4 doesn't enforce the even-odd reg restriction.

Do note that for ARCompact ISA builds v3 and v4 are practically the same in terms of gcc code generation.

In terms of change management, we infer the new ABI if gcc 6.x onwards is used for building the kernel.

This also needs a stable backport to enable older kernels to work with new tools/user-space

Cc <[email protected]>

Signed-off-by Vineet Gupta <[email protected]>

arch/arc/include/uapi/asm/elf.h +9 -2

index 0f99ac8fcbb2..0037a587320d 100644
@@ -13,8 +13,15 @@
 
 /* Machine specific ELF Hdr flags */
 #define EF_ARC_OSABI_MSK	0x00000f00
-#define EF_ARC_OSABI_ORIG	0x00000000   /* MUST be zero for back-compat */
-#define EF_ARC_OSABI_CURRENT	0x00000300   /* v3 (no legacy syscalls) */
+
+#define EF_ARC_OSABI_V3		0x00000300   /* v3 (no legacy syscalls) */
+#define EF_ARC_OSABI_V4		0x00000400   /* v4 (64bit data any reg align) */
+
+#if __GNUC__ < 6
+#define EF_ARC_OSABI_CURRENT	EF_ARC_OSABI_V3
+#else
+#define EF_ARC_OSABI_CURRENT	EF_ARC_OSABI_V4
+#endif
 
 typedef unsigned long elf_greg_t;
 typedef unsigned long elf_fpregset_t;

arch/arc/kernel/process.c +1 -1

index b5db9e7fd649..be1972bd2729 100644
@@ -199,7 +199,7 @@ int elf_check_arch(const struct elf32_hdr *x)
 	}
 
 	eflags = x->e_flags;
-	if ((eflags & EF_ARC_OSABI_MSK) < EF_ARC_OSABI_CURRENT) {
+	if ((eflags & EF_ARC_OSABI_MSK) != EF_ARC_OSABI_CURRENT) {
 		pr_err("ABI mismatch - you need newer toolchain\n");
 		force_sigsegv(SIGSEGV, current);
 		return 0;

arch/arc/kernel/setup.c +4 -2

index a946400a86d0..f52a0d0dc462 100644
@@ -291,8 +291,10 @@ static char *arc_extn_mumbojumbo(int cpu_id, char *buf, int len)
 			       cpu->dccm.base_addr, TO_KB(cpu->dccm.sz),
 			       cpu->iccm.base_addr, TO_KB(cpu->iccm.sz));
 
-	n += scnprintf(buf + n, len - n,
-		       "OS ABI [v3]\t: no-legacy-syscalls\n");
+	n += scnprintf(buf + n, len - n, "OS ABI [v%d]\t: %s\n",
+			EF_ARC_OSABI_CURRENT >> 8,
+			EF_ARC_OSABI_CURRENT == EF_ARC_OSABI_V3 ?
+			"no-legacy-syscalls" : "64-bit data any register aligned");
 
 	return buf;
 }

Quoted 9 lines · On 09/05/2016 06:03 AM, [email protected] wrote:

The patch below was submitted to be applied to the 4.7-stable tree.

I fail to see how this patch meets the stable kernel rules as found at Documentation/stable_kernel_rules.txt.

I could be totally wrong, and if so, please respond to <[email protected]> and let me know why this patch should be applied. Otherwise, it is now dropped from my patch queues, never to be seen again.

Hi Greg,

We are about to switch to new version of GNU tools (gcc 6.x based) which unfortunately has a non compatible ABI change - as described in the patch.

Some of our customers are going to stick with older kernels and thus this helps them upgrade to newer tools with their existing baseline kernels.

Quoted 12 lines · Vineet Gupta

Quoted 9 lines · On 09/05/2016 06:03 AM, [email protected] wrote:

The patch below was submitted to be applied to the 4.7-stable tree.

I fail to see how this patch meets the stable kernel rules as found at Documentation/stable_kernel_rules.txt.

I could be totally wrong, and if so, please respond to <stable at vger.kernel.org> and let me know why this patch should be applied. Otherwise, it is now dropped from my patch queues, never to be seen again.

Hi Greg,

Quoted 5 lines

We are about to switch to new version of GNU tools (gcc 6.x based) which unfortunately has a non compatible ABI change - as described in the patch.

Some of our customers are going to stick with older kernels and thus this helps them upgrade to newer tools with their existing baseline kernels.

That's nice, but it's a new feature. Stick with old userspace for older kernels, and use new kernels for new userspace if you so desire.

We do allow some new gcc fixes to be backported, but that's always where we have found bugs, or build warnings. Not "we need to support gcc6 for old kernels", as really, if someone wants to update userspace, they don't update their kernel?

thanks,

greg k-h

Quoted 3 lines

Not "we need to support gcc6 for
old kernels", as really, if someone wants to update userspace, they don't update their kernel?

Quoted 3 lines · Vineet Gupta

Quoted 3 lines

Not "we need to support gcc6 for
old kernels", as really, if someone wants to update userspace, they don't update their kernel?

FWIW, I'm not arguing for the backport inclusion - I'm just trying to explain the context more.

Thing is your regular user/customer don't really care/know about these details. So there are tools bugs and more often than not the easy answer for tools providers is "this is a known issue in gcc x.y which has been fixed in gcc x2.y2 so consider upgrading". So it is for such class of users that having such backports makes life a little easy.

Quoted 7 lines · Vineet Gupta

Quoted 3 lines · Vineet Gupta

Quoted 3 lines

Not "we need to support gcc6 for
old kernels", as really, if someone wants to update userspace, they don't update their kernel?

FWIW, I'm not arguing for the backport inclusion - I'm just trying to explain the context more.

Quoted 5 lines

Thing is your regular user/customer don't really care/know about these details. So there are tools bugs and more often than not the easy answer for tools providers is "this is a known issue in gcc x.y which has been fixed in gcc x2.y2 so consider upgrading". So it is for such class of users that having such backports makes life a little easy.

That's fine, but who would be upgrading their userspace gcc and then wanting to rebuild their kernel for an old kernel release?

What prevents them from also updating their kernel?

I understand the context, I'm just trying to say that this really is a "new feature" you are wanting here from what I can tell. I'd recommend just having people upgrade their kernel :)

thanks,

greg k-h

Quoted 8 lines · Greg Kroah-Hartman

Quoted 7 lines · Vineet Gupta

Quoted 3 lines · Vineet Gupta

Quoted 3 lines

Not "we need to support gcc6 for
old kernels", as really, if someone wants to update userspace, they don't update their kernel?

FWIW, I'm not arguing for the backport inclusion - I'm just trying to explain the context more.

Quoted 7 lines

Quoted 5 lines

Thing is your regular user/customer don't really care/know about these details. So there are tools bugs and more often than not the easy answer for tools providers is "this is a known issue in gcc x.y which has been fixed in gcc x2.y2 so consider upgrading". So it is for such class of users that having such backports makes life a little easy.

That's fine, but who would be upgrading their userspace gcc and then wanting to rebuild their kernel for an old kernel release?

IMHO those are totally unrelated things. user-space gcc/tools upgrade can be forced upon customers by processor vendors (us) saying new tools come with boat load of fixes etc and more often that not it is indeed the case. OTOH, customers typically like to lock into a specific kernel baseline for longish duration because (1) they have out of tree drivers - (2) they have production systems, where they would be iffy to change to a new kernel because prev one is stable etc. I know above seem like made up points and it is easy to dismiss them given that
(1) We don't really work our processes for "enabling" out of tree stuff and (2) a new gcc is more unstable than a new kernel. But that is the mindset when you talk to them.

Quoted 1 line

What prevents them from also updating their kernel?

Their platform baseline and out of tree drivers. Given my experience with maintaining arch port, in the past, an arch rebase has been easier than rebasing the drivers because of the framework improvements, API changes....

Quoted 27 lines · Vineet Gupta

Quoted 8 lines · Greg Kroah-Hartman

Quoted 7 lines · Vineet Gupta

Quoted 3 lines · Vineet Gupta

Quoted 3 lines

Not "we need to support gcc6 for
old kernels", as really, if someone wants to update userspace, they don't update their kernel?

FWIW, I'm not arguing for the backport inclusion - I'm just trying to explain the context more.

Quoted 7 lines

Quoted 5 lines

Thing is your regular user/customer don't really care/know about these details. So there are tools bugs and more often than not the easy answer for tools providers is "this is a known issue in gcc x.y which has been fixed in gcc x2.y2 so consider upgrading". So it is for such class of users that having such backports makes life a little easy.

That's fine, but who would be upgrading their userspace gcc and then wanting to rebuild their kernel for an old kernel release?

IMHO those are totally unrelated things. user-space gcc/tools upgrade can be forced upon customers by processor vendors (us) saying new tools come with boat load of fixes etc and more often that not it is indeed the case. OTOH, customers typically like to lock into a specific kernel baseline for longish duration because (1) they have out of tree drivers - (2) they have production systems, where they would be iffy to change to a new kernel because prev one is stable etc. I know above seem like made up points and it is easy to dismiss them given that
(1) We don't really work our processes for "enabling" out of tree stuff and (2) a new gcc is more unstable than a new kernel. But that is the mindset when you talk to them.

Quoted 4 lines

Quoted 1 line

What prevents them from also updating their kernel?

Their platform baseline and out of tree drivers. Given my experience with maintaining arch port, in the past, an arch rebase has been easier than rebasing the drivers because of the framework improvements, API changes....

If they have huge patches for their kernels, adding yet-another-one for the gcc change should be just fine, right?

And you know they aren't
updating their base stable kernel release number, so even if this was added to the stable trees, they wouldn't see it :(