From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1759437AbcIMQ6r (ORCPT ); Tue, 13 Sep 2016 12:58:47 -0400 Received: from mx1.redhat.com ([209.132.183.28]:43072 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752325AbcIMQ6p (ORCPT ); Tue, 13 Sep 2016 12:58:45 -0400 Subject: Re: KVM patches applied in weird order in -stable To: Greg KH References: <20160913145100.GK3872@codeblueprint.co.uk> <20160913145809.GA28002@kroah.com> <1b809ad3-2fee-b67d-fcbb-fb35e8fa7f30@redhat.com> <20160913165704.GA27570@kroah.com> Cc: Matt Fleming , linux-kernel@vger.kernel.org, stable@vger.kernel.org From: Paolo Bonzini Message-ID: Date: Tue, 13 Sep 2016 18:58:40 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <20160913165704.GA27570@kroah.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.26]); Tue, 13 Sep 2016 16:58:44 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 13/09/2016 18:57, Greg KH wrote: >>>> > >> [0] commit 4e422bdd2f84 ("KVM: x86: fix missed hardware breakpoints") >>>> > >> [1] commit 172b2386ed16 ("KVM: x86: fix missed hardware breakpoints") >>>> > >> [2] commit 70e4da7a8ff6 ("KVM: x86: fix root cause for missed hardware breakpoints") >>>> > >> >>>> > >> but this is the order for linux-4.4.y >>>> > >> >>>> > >> [1] commit fc90441e728a ("KVM: x86: fix missed hardware breakpoints") >>>> > >> [2] commit 25e8618619a5 ("KVM: x86: fix root cause for missed hardware breakpoints") >>>> > >> [0] commit 0f6e5e26e68f ("KVM: x86: fix missed hardware breakpoints") >>>> > >> >>>> > >> The upshot is that KVM_DEBUGREG_RELOAD is always set when returning >>>> > >> from kvm_arch_vcpu_load() in stable, but not in Linus' tree. >>> > > >>> > > How would applying these in a different order cause breakage? >> > >> > [2] is reverting [0]+[1]. Stable is not due to the different order. > Really? Are you sure that [0] and [1] isn't just the same commit? It > looks like that to me. It is; "git" automatically resolved the conflicts when merging [1], and then [2] reverted the change. In stable, changing the order created a different conflict resolution. Paolo