The patch below was submitted to be applied to the 4.18-stable tree.
I fail to see how this patch meets the stable kernel rules as found at Documentation/process/stable-kernel-rules.rst.
I could be totally wrong, and if so, please respond to stable@vger.kernel.org and let me know why this patch should be applied. Otherwise, it is now dropped from my patch queues, never to be seen again.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
From 7288bde1f9df6c1475675419bdd7725ce84dec56 Mon Sep 17 00:00:00 2001
From: Arnd Bergmann arnd@arndb.de Date: Mon, 20 Aug 2018 23:37:50 +0200 Subject: [PATCH] x86: kvm: avoid unused variable warning
Removing one of the two accesses of the maxphyaddr variable led to a harmless warning:
arch/x86/kvm/x86.c: In function 'kvm_set_mmio_spte_mask': arch/x86/kvm/x86.c:6563:6: error: unused variable 'maxphyaddr' [-Werror=unused-variable]
Removing the #ifdef seems to be the nicest workaround, as it makes the code look cleaner than adding another #ifdef.
Fixes: 28a1f3ac1d0c ("kvm: x86: Set highest physical address bits in non-present/reserved SPTEs") Signed-off-by: Arnd Bergmann arnd@arndb.de Cc: stable@vger.kernel.org # L1TF Signed-off-by: Paolo Bonzini pbonzini@redhat.com
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c index f7dff0457846..14ee9a814888 100644 --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -6576,14 +6576,12 @@ static void kvm_set_mmio_spte_mask(void) /* Set the present bit. */ mask |= 1ull;
-#ifdef CONFIG_X86_64 /* * If reserved bit is not supported, clear the present bit to disable * mmio page fault. */ - if (maxphyaddr == 52) + if (IS_ENABLED(CONFIG_X86_64) && maxphyaddr == 52) mask &= ~1ull; -#endif
kvm_mmu_set_mmio_spte_mask(mask, mask); }
On Sat, Sep 01, 2018 at 02:24:23PM -0700, gregkh@linuxfoundation.org wrote:
The patch below was submitted to be applied to the 4.18-stable tree.
I fail to see how this patch meets the stable kernel rules as found at Documentation/process/stable-kernel-rules.rst.
Oops, hit the wrong button, this should have been my "this did not apply" message, sorry about that.
This doesn't apply because:
I could be totally wrong, and if so, please respond to stable@vger.kernel.org and let me know why this patch should be applied. Otherwise, it is now dropped from my patch queues, never to be seen again.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
From 7288bde1f9df6c1475675419bdd7725ce84dec56 Mon Sep 17 00:00:00 2001
From: Arnd Bergmann arnd@arndb.de Date: Mon, 20 Aug 2018 23:37:50 +0200 Subject: [PATCH] x86: kvm: avoid unused variable warning
Removing one of the two accesses of the maxphyaddr variable led to a harmless warning:
arch/x86/kvm/x86.c: In function 'kvm_set_mmio_spte_mask': arch/x86/kvm/x86.c:6563:6: error: unused variable 'maxphyaddr' [-Werror=unused-variable]
Removing the #ifdef seems to be the nicest workaround, as it makes the code look cleaner than adding another #ifdef.
Fixes: 28a1f3ac1d0c ("kvm: x86: Set highest physical address bits in non-present/reserved SPTEs")
that commit is not in a stable tree. It wasn't marked to be backpoted, should it?
thanks,
greg k-h
On Sat, Sep 1, 2018 at 11:39 PM Greg KH gregkh@linuxfoundation.org wrote:
On Sat, Sep 01, 2018 at 02:24:23PM -0700, gregkh@linuxfoundation.org wrote:
The patch below was submitted to be applied to the 4.18-stable tree.
I fail to see how this patch meets the stable kernel rules as found at Documentation/process/stable-kernel-rules.rst.
Oops, hit the wrong button, this should have been my "this did not apply" message, sorry about that.
This doesn't apply because:
Fixes: 28a1f3ac1d0c ("kvm: x86: Set highest physical address bits in non-present/reserved SPTEs")
that commit is not in a stable tree. It wasn't marked to be backpoted, should it?
When I sent my compile fix, I did not expect either one to need a backport. Looking at 28a1f3ac1d0c more closely does make it sound like it should be. Junaid Shahid wrote the patch originally, let's see what he thinks.
Arnd
On 09/03/2018 02:27 AM, Arnd Bergmann wrote:
On Sat, Sep 1, 2018 at 11:39 PM Greg KH gregkh@linuxfoundation.org wrote:
On Sat, Sep 01, 2018 at 02:24:23PM -0700, gregkh@linuxfoundation.org wrote:
The patch below was submitted to be applied to the 4.18-stable tree.
I fail to see how this patch meets the stable kernel rules as found at Documentation/process/stable-kernel-rules.rst.
Oops, hit the wrong button, this should have been my "this did not apply" message, sorry about that.
This doesn't apply because:
Fixes: 28a1f3ac1d0c ("kvm: x86: Set highest physical address bits in non-present/reserved SPTEs")
that commit is not in a stable tree. It wasn't marked to be backpoted, should it?
When I sent my compile fix, I did not expect either one to need a backport. Looking at 28a1f3ac1d0c more closely does make it sound like it should be. Junaid Shahid wrote the patch originally, let's see what he thinks.
Arnd
Yes, I think that it would be a good idea to include 28a1f3ac1d0c in the stable tree, as it contains a security fix related to L1TF.
Thanks, Junaid
On Tue, Sep 04, 2018 at 12:17:57PM -0700, Junaid Shahid wrote:
On 09/03/2018 02:27 AM, Arnd Bergmann wrote:
On Sat, Sep 1, 2018 at 11:39 PM Greg KH gregkh@linuxfoundation.org wrote:
On Sat, Sep 01, 2018 at 02:24:23PM -0700, gregkh@linuxfoundation.org wrote:
The patch below was submitted to be applied to the 4.18-stable tree.
I fail to see how this patch meets the stable kernel rules as found at Documentation/process/stable-kernel-rules.rst.
Oops, hit the wrong button, this should have been my "this did not apply" message, sorry about that.
This doesn't apply because:
Fixes: 28a1f3ac1d0c ("kvm: x86: Set highest physical address bits in non-present/reserved SPTEs")
that commit is not in a stable tree. It wasn't marked to be backpoted, should it?
When I sent my compile fix, I did not expect either one to need a backport. Looking at 28a1f3ac1d0c more closely does make it sound like it should be. Junaid Shahid wrote the patch originally, let's see what he thinks.
Arnd
Yes, I think that it would be a good idea to include 28a1f3ac1d0c in the stable tree, as it contains a security fix related to L1TF.
Ok, now applied to 4.18.y and 4.14.y, thanks.
greg k-h
linux-stable-mirror@lists.linaro.org