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?

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

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?

[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

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
>

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

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