Message-ID: <829c2b8807b4e6c59843b3ab85ca3ccc6cae8373.camel@mellanox.com>
Date:   Thu, 16 Apr 2020 21:32:47 +0000
From:   Saeed Mahameed <saeedm@...lanox.com>
To:     "sashal@...nel.org" <sashal@...nel.org>
CC:     "ecree@...arflare.com" <ecree@...arflare.com>,
        "gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
        "stable@...r.kernel.org" <stable@...r.kernel.org>,
        "kuba@...nel.org" <kuba@...nel.org>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "gerlitz.or@...il.com" <gerlitz.or@...il.com>,
        "davem@...emloft.net" <davem@...emloft.net>
Subject: Re: [PATCH AUTOSEL 4.9 09/26] net/mlx5e: Init ethtool steering for
 representors

On Thu, 2020-04-16 at 15:53 -0400, Sasha Levin wrote:
> On Thu, Apr 16, 2020 at 07:31:25PM +0000, Saeed Mahameed wrote:
> > On Thu, 2020-04-16 at 19:20 +0200, Greg KH wrote:
> > > So far the AUTOSEL tool has found so many real bugfixes that it
> > > isn't
> > > funny.  If you don't like it, fine, but it has proven itself
> > > _way_
> > > beyond my wildest hopes already, and it just keeps getting
> > > better.
> > > 
> > 
> > Now i really don't know what the right balance here, in on one
> > hand,
> > autosel is doing a great job, on the other hand we know it can
> > screw up
> > in some cases, and we know it will.
> > 
> > So we decided to make sacrifices for the greater good ? :)
> 
> autosel is going to screw up, I'm going to screw up, you're going to
> screw up, and Linus is going screw up. The existence of the stable
> trees
> and a "Fixes:" tag is an admission we all screw up, right?
> 

Right, so fix this AI and we get one less reason to screw up ?

> If you're willing to accept that we all make mistakes, you should
> also
> accept that we're making mistakes everywhere: we write buggy code, we
> fail at reviews, we forget tags, and we suck at backporting patches.
> 
> If we agree so far, then why do you assume that the same people who
> do
> the above also perfectly tag their commits, and do perfect selection
> of
> patches for stable? "I'm always right except when I'm wrong".

I am welling to accept people making mistakes, but not the AI.. 

I am not saying people should be 100% flawless, but i am assuming AI is
100% flawless. if I find a bug in AI I fix. same goes for autosel AI,
it must get fixed.

What you are really saying: I don't like bugs, so i wrote an AI that
fixes bugs but also can make bugs itself.

> 
> My view of the the path forward with stable trees is that we have to
> beef up our validation and testing story to be able to catch these
> issues better, rather than place arbitrary limitations on parts of
> the
> process. To me your suggestions around the Fixes: tag sound like
> "Never
> use kmalloc() because people often forget to free memory!" will it
> prevent memory leaks? sure, but it'll also prevent useful patches
> from
> coming it...
> 

No, I will let people do what people do best (make more bugs) this is
more than fine.

if it is necessary and we have a magical solution, i will write good AI
with no false positives to fix or help avoid memleacks.

BUT if i can't achieve 100% success rate, and i might end up
introducing memleack with my AI, then I wouldn't use AI at all.

We have different views on things.. if i know AI is using kmalloc
wrongly, I fix it, end of story :).

fact: Your AI is broken, can introduce _new_ un-called for bugs, even
it is very very very good 99.99% of the cases. 

You are welling to roll the dice, i am not .. 

> Here's my suggestion: give us a test rig we can run our stable
> release
> candidates through. Something that simulates "real" load that
> customers
> are using. We promise that we won't release a stable kernel if your
> tests are failing.
> 

I will be more than glad to do so, is there a formal process for such
thing ?

Powered by blists - more mailing lists