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

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

[gregkh]

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

thanks,

greg k-h

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

>From 840c054fd0efb048df6fceb0c46385ec5b66dfe6 Mon Sep 17 00:00:00 2001
From: Vineet Gupta <vgupta@synopsys.com>
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: <stable@vger.kernel.org>
Signed-off-by: Vineet Gupta <vgupta@synopsys.com>

diff --git a/arch/arc/include/uapi/asm/elf.h b/arch/arc/include/uapi/asm/elf.h
index 0f99ac8fcbb2..0037a587320d 100644
--- a/arch/arc/include/uapi/asm/elf.h
+++ b/arch/arc/include/uapi/asm/elf.h
@@ -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;
diff --git a/arch/arc/kernel/process.c b/arch/arc/kernel/process.c
index b5db9e7fd649..be1972bd2729 100644
--- a/arch/arc/kernel/process.c
+++ b/arch/arc/kernel/process.c
@@ -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;
diff --git a/arch/arc/kernel/setup.c b/arch/arc/kernel/setup.c
index a946400a86d0..f52a0d0dc462 100644
--- a/arch/arc/kernel/setup.c
+++ b/arch/arc/kernel/setup.c
@@ -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;
 }

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

[Vineet Gupta]

On 09/05/2016 06:03 AM, gregkh@linuxfoundation.org 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@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,

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.

Thx,
-Vineet

>
> thanks,
>
> greg k-h
>
> ------------------ original commit in Linus's tree ------------------
>
> From 840c054fd0efb048df6fceb0c46385ec5b66dfe6 Mon Sep 17 00:00:00 2001
> From: Vineet Gupta <vgupta@synopsys.com>
> 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: <stable@vger.kernel.org>
> Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
>
> diff --git a/arch/arc/include/uapi/asm/elf.h b/arch/arc/include/uapi/asm/elf.h
> index 0f99ac8fcbb2..0037a587320d 100644
> --- a/arch/arc/include/uapi/asm/elf.h
> +++ b/arch/arc/include/uapi/asm/elf.h
> @@ -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;
> diff --git a/arch/arc/kernel/process.c b/arch/arc/kernel/process.c
> index b5db9e7fd649..be1972bd2729 100644
> --- a/arch/arc/kernel/process.c
> +++ b/arch/arc/kernel/process.c
> @@ -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;
> diff --git a/arch/arc/kernel/setup.c b/arch/arc/kernel/setup.c
> index a946400a86d0..f52a0d0dc462 100644
> --- a/arch/arc/kernel/setup.c
> +++ b/arch/arc/kernel/setup.c
> @@ -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;
>  }
>
>

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

[gregkh]

On Tue, Sep 06, 2016 at 09:50:46AM -0700, Vineet Gupta wrote:
> On 09/05/2016 06:03 AM, gregkh@linuxfoundation.org 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@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,
> 
> 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

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

[Vineet Gupta]

On 09/06/2016 12:39 PM, gregkh@linuxfoundation.org wrote:
> On Tue, Sep 06, 2016 at 09:50:46AM -0700, Vineet Gupta wrote:
>> On 09/05/2016 06:03 AM, gregkh@linuxfoundation.org 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@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,
>>
>> 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.

I understand your point. This is what we did at the time of upstreaming the kernel
- and was something I was hoping to avoid this time because this is a flag day
change. People get locked into kernel version or tools - when the kernel code
itself didn't really change a bit.

But if this really is against the norms of stable backports, then I suppose we
can't do much ?

Thx,
-Vineet

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

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

[Vineet Gupta]

On 09/06/2016 12:39 PM, gregkh@linuxfoundation.org wrote:
> On Tue, Sep 06, 2016@09:50:46AM -0700, Vineet Gupta wrote:
>> On 09/05/2016 06:03 AM, gregkh@linuxfoundation.org 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,
>>
>> 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.

I understand your point. This is what we did at the time of upstreaming the kernel
- and was something I was hoping to avoid this time because this is a flag day
change. People get locked into kernel version or tools - when the kernel code
itself didn't really change a bit.

But if this really is against the norms of stable backports, then I suppose we
can't do much ?

Thx,
-Vineet

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

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

[Vineet Gupta]

On 09/06/2016 01:22 PM, Vineet Gupta wrote:
> > 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.

Thx,
-Vineet

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

[Vineet Gupta]

On 09/06/2016 01:22 PM, Vineet Gupta wrote:
> > 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.

Thx,
-Vineet

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

[Greg Kroah-Hartman]

On Tue, Sep 06, 2016 at 01:28:45PM -0700, Vineet Gupta wrote:
> On 09/06/2016 01:22 PM, Vineet Gupta wrote:
> > > 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.

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

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

[Greg Kroah-Hartman]

On Tue, Sep 06, 2016@01:28:45PM -0700, Vineet Gupta wrote:
> On 09/06/2016 01:22 PM, Vineet Gupta wrote:
> > > 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.

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

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

[Vineet Gupta]

On 09/06/2016 11:28 PM, Greg Kroah-Hartman wrote:
> On Tue, Sep 06, 2016 at 01:28:45PM -0700, Vineet Gupta wrote:
>> On 09/06/2016 01:22 PM, Vineet Gupta wrote:
>>>> 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.
> 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.

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


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

That's what I recommend them too, all the time, but forcing this with a tools
upgrade really enforces them and they need to pick a side, before 4.x or after 4.x
which is not nice....

Thx,
-Vineet

>
> thanks,
>
> greg k-h
>

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

[Vineet Gupta]

On 09/06/2016 11:28 PM, Greg Kroah-Hartman wrote:
> On Tue, Sep 06, 2016@01:28:45PM -0700, Vineet Gupta wrote:
>> On 09/06/2016 01:22 PM, Vineet Gupta wrote:
>>>> 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.
> 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.

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


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

That's what I recommend them too, all the time, but forcing this with a tools
upgrade really enforces them and they need to pick a side, before 4.x or after 4.x
which is not nice....

Thx,
-Vineet

>
> thanks,
>
> greg k-h
>

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

[Greg Kroah-Hartman]

On Wed, Sep 07, 2016 at 09:38:25AM -0700, Vineet Gupta wrote:
> On 09/06/2016 11:28 PM, Greg Kroah-Hartman wrote:
> > On Tue, Sep 06, 2016 at 01:28:45PM -0700, Vineet Gupta wrote:
> >> On 09/06/2016 01:22 PM, Vineet Gupta wrote:
> >>>> 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.
> > 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.
> 
> >  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 :(

Unless ARC customers are better than others?

thanks,

greg k-h

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

[Greg Kroah-Hartman]

On Wed, Sep 07, 2016@09:38:25AM -0700, Vineet Gupta wrote:
> On 09/06/2016 11:28 PM, Greg Kroah-Hartman wrote:
> > On Tue, Sep 06, 2016@01:28:45PM -0700, Vineet Gupta wrote:
> >> On 09/06/2016 01:22 PM, Vineet Gupta wrote:
> >>>> 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.
> > 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.
> 
> >  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 :(

Unless ARC customers are better than others?

thanks,

greg k-h

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

[Vineet Gupta]

On 09/09/2016 04:39 AM, Greg Kroah-Hartman wrote:
> On Wed, Sep 07, 2016 at 09:38:25AM -0700, Vineet Gupta wrote:
>> On 09/06/2016 11:28 PM, Greg Kroah-Hartman wrote:
>>> On Tue, Sep 06, 2016 at 01:28:45PM -0700, Vineet Gupta wrote:
>>>> On 09/06/2016 01:22 PM, Vineet Gupta wrote:
>>>>>> 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.
>>> 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.
>>
>>>  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? 

That is true.

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

I'd presume they will follow the stable bumps - otherwise it is pointless to ask
for backport in first place.

-Vineet

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

[Vineet Gupta]

On 09/09/2016 04:39 AM, Greg Kroah-Hartman wrote:
> On Wed, Sep 07, 2016@09:38:25AM -0700, Vineet Gupta wrote:
>> On 09/06/2016 11:28 PM, Greg Kroah-Hartman wrote:
>>> On Tue, Sep 06, 2016@01:28:45PM -0700, Vineet Gupta wrote:
>>>> On 09/06/2016 01:22 PM, Vineet Gupta wrote:
>>>>>> 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.
>>> 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.
>>
>>>  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? 

That is true.

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

I'd presume they will follow the stable bumps - otherwise it is pointless to ask
for backport in first place.

-Vineet