From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lb0-f182.google.com ([209.85.217.182]:36341 "EHLO mail-lb0-f182.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933396AbbEKSoI (ORCPT ); Mon, 11 May 2015 14:44:08 -0400 Received: by lbbqq2 with SMTP id qq2so100515504lbb.3 for ; Mon, 11 May 2015 11:44:05 -0700 (PDT) Date: Mon, 11 May 2015 20:44:13 +0200 From: Christoffer Dall To: Greg KH Cc: shannon.zhao@linaro.org, stable@vger.kernel.org, Marc Zyngier , Alex =?iso-8859-1?Q?Benn=E9e?= Subject: Re: [PATCH for 3.14.y stable 47/47] arm/arm64: KVM: Keep elrsr/aisr in sync with software model Message-ID: <20150511184413.GA20917@cbox> References: <1430704362-6292-1-git-send-email-shannon.zhao@linaro.org> <1430704362-6292-48-git-send-email-shannon.zhao@linaro.org> <20150511151707.GA23043@kroah.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150511151707.GA23043@kroah.com> Sender: stable-owner@vger.kernel.org List-ID: Hi Greg, On Mon, May 11, 2015 at 08:17:07AM -0700, Greg KH wrote: > On Mon, May 04, 2015 at 09:52:42AM +0800, shannon.zhao@linaro.org wrote: > > From: Christoffer Dall > > > > commit ae705930fca6322600690df9dc1c7d0516145a93 upstream. > > No, that's not what the patch below really is. > > Do I have to go back by hand and verify each one of these really is the > patch you say it is? That's a major pain... > This is a backport of the referenced commit, but it couldn't be applied directly because of the churn in the vgic code. I believed that the commit X upstream notation would indicate the equivalent fix upstream, not the *exact* commit for the relevant stable kernel. Apologies if that was an incorrect assumption. I believe this is the only patch which was significantly rewritten because of the churn in the vgic code and enough users are seeing this in various distro kernels that I figured it was important to refactor and backport. What would you like me to do with this patch? Note that I didn't understand that this is wrong from reading Documentation/stable_kernel_rules.txt, which may just be because I'm being stupid. Is the procedure that we're violating documented somewhere? Thanks, -Christoffer