Subject: Re: [PATCH 4.14 108/159] kvm, mm: account kvm related kmem slabs to
 kmemcg
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        Michal Hocko <mhocko@kernel.org>
Cc: alexander.levin@verizon.com,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "stable@vger.kernel.org" <stable@vger.kernel.org>,
        Shakeel Butt <shakeelb@google.com>
References: <20171222084623.668990192@linuxfoundation.org>
 <20171222084629.570989756@linuxfoundation.org>
 <20171222093407.GN4831@dhcp22.suse.cz> <20171222124122.GA30743@kroah.com>
 <20171222130607.GQ4831@dhcp22.suse.cz>
 <20171222174002.6qiqllf3bhmjangn@sasha-lappy>
 <20171222175616.GS4831@dhcp22.suse.cz> <20171223092437.GI13832@kroah.com>
From: Paolo Bonzini <pbonzini@redhat.com>
Message-ID: <6884ca9a-f63d-d6ef-9ead-68ab672098ec@redhat.com>
Date: Wed, 27 Dec 2017 11:30:38 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101
 Thunderbird/52.5.0
MIME-Version: 1.0
In-Reply-To: <20171223092437.GI13832@kroah.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2555
Lines: 52

On 23/12/2017 10:24, Greg Kroah-Hartman wrote:
> For many subsystems, the maintainers _never_ mark patches for stable.
> Others, they catch maybe half of the things they should be applying.
> 
> KVM is one such example of the "half" group, they mark patches as
> resolving CVE issues at times, yet don't mark them for stable.  So when
> I see a patch like this, it triggers the "oh, look, KVM doing the same
> thing again", so I take the patch and of course cc: the
> developers/maintainers so they can object if they want to.

In general there are some cases where I tend to be conservative on
applying the "stable" tag, for example:

1) sometimes I'm not very familiar with API changes in the other
subsystems (this was the case for this patch).  If I am not sure of the
amount of backporting effort required, and the bug is not super
important, I don't mark it as stable because I don't want to later drop
a complex backport on the floor.  I prefer to have fewer patches
applied, but know that the fixes are backported to all branches.

2) not all bugs are equal; a WARN_ON_ONCE from a syzkaller testcase for
example doesn't really matter to a cloud provider that uses KVM, because
invalid API usage is not controlled by the customer.  But an oops or
BUG_ON probably *will* get CCed to stable.  So some patches for
syzkaller bugs may be CCed, some may not.

IIRC the CVE that you mention was a guest user->kernel escalation, but
it didn't affect Linux guests at all, and it couldn't be fixed
completely on Windows guests because Windows has another bug in the same
area.  Plus, I knew there would be different conflicts on all LTS
branches, so I decided to not mark it for stable.  I did dutifully
provide a backport when someone (either you or Ben Hutchings) asked for
one, though.

It does happen that Radim or I forget to Cc stable, so I'm okay with you
picking up more patches than what I mark and I will happily do the
backports for you.  Still, there is some thought put into whether to CC
stable or not. :)

Thanks,

Paolo

> Over time you get to know what subsystems are like this and what are
> not.  MM is one that is really good, I almost never take a mm patch
> without being told explicitly to do so.  Others are horrible and never
> mark anything, so stuff has to be picked up manually through Sasha's
> process or through other ways.
> 
> So it's not a perfect system, but it seems to work "good enough", and if
> you ever have any questions about any patch, always feel free to ask,
> there's usually a story behind almost every one...