All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg KH <gregkh@linuxfoundation.org>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: Matt Fleming <matt@codeblueprint.co.uk>,
	linux-kernel@vger.kernel.org, stable@vger.kernel.org
Subject: Re: KVM patches applied in weird order in -stable
Date: Tue, 13 Sep 2016 18:57:04 +0200	[thread overview]
Message-ID: <20160913165704.GA27570@kroah.com> (raw)
In-Reply-To: <1b809ad3-2fee-b67d-fcbb-fb35e8fa7f30@redhat.com>

On Tue, Sep 13, 2016 at 06:26:12PM +0200, Paolo Bonzini wrote:
> 
> 
> On 13/09/2016 16:58, Greg KH wrote:
> > [adding stable@ as this is a stable issue, not a 'normal' issue]
> > 
> > On Tue, Sep 13, 2016 at 03:51:00PM +0100, Matt Fleming wrote:
> >> Folks,
> >>
> >> While hunting down a performance issue involving KVM I was surprised
> >> to see "native_set_debugreg()" as the first entry in `perf top`.
> >>
> >> Digging deeper, it looks as though the following patches were applied
> >> in the wrong order in -stable. This is the order as they appear in
> >> Linus' tree,
> >>
> >>  [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.

> > And if this is a problem, can you please send me a patch to fix it up?
> 
> Yup, on the way.

thanks,

greg k-h

  reply	other threads:[~2016-09-13 16:57 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-09-13 14:51 KVM patches applied in weird order in -stable Matt Fleming
2016-09-13 14:58 ` Greg KH
2016-09-13 16:26   ` Paolo Bonzini
2016-09-13 16:57     ` Greg KH [this message]
2016-09-13 16:58       ` Paolo Bonzini
2016-09-14  1:19         ` Greg KH

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160913165704.GA27570@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=matt@codeblueprint.co.uk \
    --cc=pbonzini@redhat.com \
    --cc=stable@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.