--- /dev/null
+From b9428e92406135ea5211a00aece1e1a770676fba Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 27 Nov 2020 12:33:54 +0100
+Subject: ext4: don't remount read-only with errors=continue on reboot
+
+From: Jan Kara <jack@suse.cz>
+
+[ Upstream commit b08070eca9e247f60ab39d79b2c25d274750441f ]
+
+ext4_handle_error() with errors=continue mount option can accidentally
+remount the filesystem read-only when the system is rebooting. Fix that.
+
+Fixes: 1dc1097ff60e ("ext4: avoid panic during forced reboot")
+Signed-off-by: Jan Kara <jack@suse.cz>
+Reviewed-by: Andreas Dilger <adilger@dilger.ca>
+Cc: stable@kernel.org
+Link: https://lore.kernel.org/r/20201127113405.26867-2-jack@suse.cz
+Signed-off-by: Theodore Ts'o <tytso@mit.edu>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ fs/ext4/super.c | 14 ++++++--------
+ 1 file changed, 6 insertions(+), 8 deletions(-)
+
+diff --git a/fs/ext4/super.c b/fs/ext4/super.c
+index ee96f504ed782..e9e9f09f5370d 100644
+--- a/fs/ext4/super.c
++++ b/fs/ext4/super.c
+@@ -454,19 +454,17 @@ static bool system_going_down(void)
+
+ static void ext4_handle_error(struct super_block *sb)
+ {
++ journal_t *journal = EXT4_SB(sb)->s_journal;
++
+ if (test_opt(sb, WARN_ON_ERROR))
+ WARN_ON_ONCE(1);
+
+- if (sb_rdonly(sb))
++ if (sb_rdonly(sb) || test_opt(sb, ERRORS_CONT))
+ return;
+
+- if (!test_opt(sb, ERRORS_CONT)) {
+- journal_t *journal = EXT4_SB(sb)->s_journal;
+-
+- EXT4_SB(sb)->s_mount_flags |= EXT4_MF_FS_ABORTED;
+- if (journal)
+- jbd2_journal_abort(journal, -EIO);
+- }
++ EXT4_SB(sb)->s_mount_flags |= EXT4_MF_FS_ABORTED;
++ if (journal)
++ jbd2_journal_abort(journal, -EIO);
+ /*
+ * We force ERRORS_RO behavior when system is rebooting. Otherwise we
+ * could panic during 'reboot -f' as the underlying device got already
+--
+2.27.0
+
--- /dev/null
+From 9cd5c187a6036593d5b407d903d6f91457c290db Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 5 Feb 2020 16:10:52 +0100
+Subject: KVM: SVM: relax conditions for allowing MSR_IA32_SPEC_CTRL accesses
+
+From: Paolo Bonzini <pbonzini@redhat.com>
+
+[ Upstream commit df7e8818926eb4712b67421442acf7d568fe2645 ]
+
+Userspace that does not know about the AMD_IBRS bit might still
+allow the guest to protect itself with MSR_IA32_SPEC_CTRL using
+the Intel SPEC_CTRL bit. However, svm.c disallows this and will
+cause a #GP in the guest when writing to the MSR. Fix this by
+loosening the test and allowing the Intel CPUID bit, and in fact
+allow the AMD_STIBP bit as well since it allows writing to
+MSR_IA32_SPEC_CTRL too.
+
+Reported-by: Zhiyi Guo <zhguo@redhat.com>
+Analyzed-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
+Analyzed-by: Laszlo Ersek <lersek@redhat.com>
+Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ arch/x86/kvm/svm.c | 4 ++++
+ 1 file changed, 4 insertions(+)
+
+diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
+index a0c3d1b4b295b..f513110983d4c 100644
+--- a/arch/x86/kvm/svm.c
++++ b/arch/x86/kvm/svm.c
+@@ -4209,6 +4209,8 @@ static int svm_get_msr(struct kvm_vcpu *vcpu, struct msr_data *msr_info)
+ break;
+ case MSR_IA32_SPEC_CTRL:
+ if (!msr_info->host_initiated &&
++ !guest_cpuid_has(vcpu, X86_FEATURE_SPEC_CTRL) &&
++ !guest_cpuid_has(vcpu, X86_FEATURE_AMD_STIBP) &&
+ !guest_cpuid_has(vcpu, X86_FEATURE_AMD_IBRS) &&
+ !guest_cpuid_has(vcpu, X86_FEATURE_AMD_SSBD))
+ return 1;
+@@ -4312,6 +4314,8 @@ static int svm_set_msr(struct kvm_vcpu *vcpu, struct msr_data *msr)
+ break;
+ case MSR_IA32_SPEC_CTRL:
+ if (!msr->host_initiated &&
++ !guest_cpuid_has(vcpu, X86_FEATURE_SPEC_CTRL) &&
++ !guest_cpuid_has(vcpu, X86_FEATURE_AMD_STIBP) &&
+ !guest_cpuid_has(vcpu, X86_FEATURE_AMD_IBRS) &&
+ !guest_cpuid_has(vcpu, X86_FEATURE_AMD_SSBD))
+ return 1;
+--
+2.27.0
+
--- /dev/null
+From 85be72910f9280073e4f6efa25fa181f47294379 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 3 Dec 2020 09:40:15 -0500
+Subject: KVM: x86: reinstate vendor-agnostic check on SPEC_CTRL cpuid bits
+
+From: Paolo Bonzini <pbonzini@redhat.com>
+
+[ Upstream commit 39485ed95d6b83b62fa75c06c2c4d33992e0d971 ]
+
+Until commit e7c587da1252 ("x86/speculation: Use synthetic bits for
+IBRS/IBPB/STIBP"), KVM was testing both Intel and AMD CPUID bits before
+allowing the guest to write MSR_IA32_SPEC_CTRL and MSR_IA32_PRED_CMD.
+Testing only Intel bits on VMX processors, or only AMD bits on SVM
+processors, fails if the guests are created with the "opposite" vendor
+as the host.
+
+While at it, also tweak the host CPU check to use the vendor-agnostic
+feature bit X86_FEATURE_IBPB, since we only care about the availability
+of the MSR on the host here and not about specific CPUID bits.
+
+Fixes: e7c587da1252 ("x86/speculation: Use synthetic bits for IBRS/IBPB/STIBP")
+Cc: stable@vger.kernel.org
+Reported-by: Denis V. Lunev <den@openvz.org>
+Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ arch/x86/kvm/cpuid.h | 14 ++++++++++++++
+ arch/x86/kvm/svm.c | 13 +++----------
+ arch/x86/kvm/vmx.c | 6 +++---
+ 3 files changed, 20 insertions(+), 13 deletions(-)
+
+diff --git a/arch/x86/kvm/cpuid.h b/arch/x86/kvm/cpuid.h
+index d78a61408243f..7dec43b2c4205 100644
+--- a/arch/x86/kvm/cpuid.h
++++ b/arch/x86/kvm/cpuid.h
+@@ -154,6 +154,20 @@ static inline int guest_cpuid_stepping(struct kvm_vcpu *vcpu)
+ return x86_stepping(best->eax);
+ }
+
++static inline bool guest_has_spec_ctrl_msr(struct kvm_vcpu *vcpu)
++{
++ return (guest_cpuid_has(vcpu, X86_FEATURE_SPEC_CTRL) ||
++ guest_cpuid_has(vcpu, X86_FEATURE_AMD_STIBP) ||
++ guest_cpuid_has(vcpu, X86_FEATURE_AMD_IBRS) ||
++ guest_cpuid_has(vcpu, X86_FEATURE_AMD_SSBD));
++}
++
++static inline bool guest_has_pred_cmd_msr(struct kvm_vcpu *vcpu)
++{
++ return (guest_cpuid_has(vcpu, X86_FEATURE_SPEC_CTRL) ||
++ guest_cpuid_has(vcpu, X86_FEATURE_AMD_IBPB));
++}
++
+ static inline bool supports_cpuid_fault(struct kvm_vcpu *vcpu)
+ {
+ return vcpu->arch.msr_platform_info & MSR_PLATFORM_INFO_CPUID_FAULT;
+diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
+index f513110983d4c..d2dc734f5bd0d 100644
+--- a/arch/x86/kvm/svm.c
++++ b/arch/x86/kvm/svm.c
+@@ -4209,10 +4209,7 @@ static int svm_get_msr(struct kvm_vcpu *vcpu, struct msr_data *msr_info)
+ break;
+ case MSR_IA32_SPEC_CTRL:
+ if (!msr_info->host_initiated &&
+- !guest_cpuid_has(vcpu, X86_FEATURE_SPEC_CTRL) &&
+- !guest_cpuid_has(vcpu, X86_FEATURE_AMD_STIBP) &&
+- !guest_cpuid_has(vcpu, X86_FEATURE_AMD_IBRS) &&
+- !guest_cpuid_has(vcpu, X86_FEATURE_AMD_SSBD))
++ !guest_has_spec_ctrl_msr(vcpu))
+ return 1;
+
+ msr_info->data = svm->spec_ctrl;
+@@ -4314,10 +4311,7 @@ static int svm_set_msr(struct kvm_vcpu *vcpu, struct msr_data *msr)
+ break;
+ case MSR_IA32_SPEC_CTRL:
+ if (!msr->host_initiated &&
+- !guest_cpuid_has(vcpu, X86_FEATURE_SPEC_CTRL) &&
+- !guest_cpuid_has(vcpu, X86_FEATURE_AMD_STIBP) &&
+- !guest_cpuid_has(vcpu, X86_FEATURE_AMD_IBRS) &&
+- !guest_cpuid_has(vcpu, X86_FEATURE_AMD_SSBD))
++ !guest_has_spec_ctrl_msr(vcpu))
+ return 1;
+
+ /* The STIBP bit doesn't fault even if it's not advertised */
+@@ -4344,12 +4338,11 @@ static int svm_set_msr(struct kvm_vcpu *vcpu, struct msr_data *msr)
+ break;
+ case MSR_IA32_PRED_CMD:
+ if (!msr->host_initiated &&
+- !guest_cpuid_has(vcpu, X86_FEATURE_AMD_IBPB))
++ !guest_has_pred_cmd_msr(vcpu))
+ return 1;
+
+ if (data & ~PRED_CMD_IBPB)
+ return 1;
+-
+ if (!data)
+ break;
+
+diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
+index d6bcbce6c15cb..77b9ed5223f37 100644
+--- a/arch/x86/kvm/vmx.c
++++ b/arch/x86/kvm/vmx.c
+@@ -4066,7 +4066,7 @@ static int vmx_get_msr(struct kvm_vcpu *vcpu, struct msr_data *msr_info)
+ return kvm_get_msr_common(vcpu, msr_info);
+ case MSR_IA32_SPEC_CTRL:
+ if (!msr_info->host_initiated &&
+- !guest_cpuid_has(vcpu, X86_FEATURE_SPEC_CTRL))
++ !guest_has_spec_ctrl_msr(vcpu))
+ return 1;
+
+ msr_info->data = to_vmx(vcpu)->spec_ctrl;
+@@ -4180,7 +4180,7 @@ static int vmx_set_msr(struct kvm_vcpu *vcpu, struct msr_data *msr_info)
+ break;
+ case MSR_IA32_SPEC_CTRL:
+ if (!msr_info->host_initiated &&
+- !guest_cpuid_has(vcpu, X86_FEATURE_SPEC_CTRL))
++ !guest_has_spec_ctrl_msr(vcpu))
+ return 1;
+
+ /* The STIBP bit doesn't fault even if it's not advertised */
+@@ -4210,7 +4210,7 @@ static int vmx_set_msr(struct kvm_vcpu *vcpu, struct msr_data *msr_info)
+ break;
+ case MSR_IA32_PRED_CMD:
+ if (!msr_info->host_initiated &&
+- !guest_cpuid_has(vcpu, X86_FEATURE_SPEC_CTRL))
++ !guest_has_pred_cmd_msr(vcpu))
+ return 1;
+
+ if (data & ~PRED_CMD_IBPB)
+--
+2.27.0
+
--- /dev/null
+From 6055117c0d929ac4784e06abfa699b1ed13a28c1 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 22 Oct 2020 14:05:46 +0000
+Subject: powerpc/bitops: Fix possible undefined behaviour with fls() and
+ fls64()
+
+From: Christophe Leroy <christophe.leroy@csgroup.eu>
+
+[ Upstream commit 1891ef21d92c4801ea082ee8ed478e304ddc6749 ]
+
+fls() and fls64() are using __builtin_ctz() and _builtin_ctzll().
+On powerpc, those builtins trivially use ctlzw and ctlzd power
+instructions.
+
+Allthough those instructions provide the expected result with
+input argument 0, __builtin_ctz() and __builtin_ctzll() are
+documented as undefined for value 0.
+
+The easiest fix would be to use fls() and fls64() functions
+defined in include/asm-generic/bitops/builtin-fls.h and
+include/asm-generic/bitops/fls64.h, but GCC output is not optimal:
+
+00000388 <testfls>:
+ 388: 2c 03 00 00 cmpwi r3,0
+ 38c: 41 82 00 10 beq 39c <testfls+0x14>
+ 390: 7c 63 00 34 cntlzw r3,r3
+ 394: 20 63 00 20 subfic r3,r3,32
+ 398: 4e 80 00 20 blr
+ 39c: 38 60 00 00 li r3,0
+ 3a0: 4e 80 00 20 blr
+
+000003b0 <testfls64>:
+ 3b0: 2c 03 00 00 cmpwi r3,0
+ 3b4: 40 82 00 1c bne 3d0 <testfls64+0x20>
+ 3b8: 2f 84 00 00 cmpwi cr7,r4,0
+ 3bc: 38 60 00 00 li r3,0
+ 3c0: 4d 9e 00 20 beqlr cr7
+ 3c4: 7c 83 00 34 cntlzw r3,r4
+ 3c8: 20 63 00 20 subfic r3,r3,32
+ 3cc: 4e 80 00 20 blr
+ 3d0: 7c 63 00 34 cntlzw r3,r3
+ 3d4: 20 63 00 40 subfic r3,r3,64
+ 3d8: 4e 80 00 20 blr
+
+When the input of fls(x) is a constant, just check x for nullity and
+return either 0 or __builtin_clz(x). Otherwise, use cntlzw instruction
+directly.
+
+For fls64() on PPC64, do the same but with __builtin_clzll() and
+cntlzd instruction. On PPC32, lets take the generic fls64() which
+will use our fls(). The result is as expected:
+
+00000388 <testfls>:
+ 388: 7c 63 00 34 cntlzw r3,r3
+ 38c: 20 63 00 20 subfic r3,r3,32
+ 390: 4e 80 00 20 blr
+
+000003a0 <testfls64>:
+ 3a0: 2c 03 00 00 cmpwi r3,0
+ 3a4: 40 82 00 10 bne 3b4 <testfls64+0x14>
+ 3a8: 7c 83 00 34 cntlzw r3,r4
+ 3ac: 20 63 00 20 subfic r3,r3,32
+ 3b0: 4e 80 00 20 blr
+ 3b4: 7c 63 00 34 cntlzw r3,r3
+ 3b8: 20 63 00 40 subfic r3,r3,64
+ 3bc: 4e 80 00 20 blr
+
+Fixes: 2fcff790dcb4 ("powerpc: Use builtin functions for fls()/__fls()/fls64()")
+Cc: stable@vger.kernel.org
+Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
+Acked-by: Segher Boessenkool <segher@kernel.crashing.org>
+Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
+Link: https://lore.kernel.org/r/348c2d3f19ffcff8abe50d52513f989c4581d000.1603375524.git.christophe.leroy@csgroup.eu
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ arch/powerpc/include/asm/bitops.h | 23 +++++++++++++++++++++--
+ 1 file changed, 21 insertions(+), 2 deletions(-)
+
+diff --git a/arch/powerpc/include/asm/bitops.h b/arch/powerpc/include/asm/bitops.h
+index ff71566dadee5..76db1c5000bd6 100644
+--- a/arch/powerpc/include/asm/bitops.h
++++ b/arch/powerpc/include/asm/bitops.h
+@@ -221,15 +221,34 @@ static __inline__ void __clear_bit_unlock(int nr, volatile unsigned long *addr)
+ */
+ static __inline__ int fls(unsigned int x)
+ {
+- return 32 - __builtin_clz(x);
++ int lz;
++
++ if (__builtin_constant_p(x))
++ return x ? 32 - __builtin_clz(x) : 0;
++ asm("cntlzw %0,%1" : "=r" (lz) : "r" (x));
++ return 32 - lz;
+ }
+
+ #include <asm-generic/bitops/builtin-__fls.h>
+
++/*
++ * 64-bit can do this using one cntlzd (count leading zeroes doubleword)
++ * instruction; for 32-bit we use the generic version, which does two
++ * 32-bit fls calls.
++ */
++#ifdef CONFIG_PPC64
+ static __inline__ int fls64(__u64 x)
+ {
+- return 64 - __builtin_clzll(x);
++ int lz;
++
++ if (__builtin_constant_p(x))
++ return x ? 64 - __builtin_clzll(x) : 0;
++ asm("cntlzd %0,%1" : "=r" (lz) : "r" (x));
++ return 64 - lz;
+ }
++#else
++#include <asm-generic/bitops/fls64.h>
++#endif
+
+ #ifdef CONFIG_PPC64
+ unsigned int __arch_hweight8(unsigned int w);
+--
+2.27.0
+
ext4-prevent-creating-duplicate-encrypted-filenames.patch
f2fs-prevent-creating-duplicate-encrypted-filenames.patch
ubifs-prevent-creating-duplicate-encrypted-filenames.patch
+vfio-pci-move-dummy_resources_list-init-in-vfio_pci_.patch
+ext4-don-t-remount-read-only-with-errors-continue-on.patch
+kvm-svm-relax-conditions-for-allowing-msr_ia32_spec_.patch
+kvm-x86-reinstate-vendor-agnostic-check-on-spec_ctrl.patch
+powerpc-bitops-fix-possible-undefined-behaviour-with.patch
--- /dev/null
+From 111e525a130fd145c676aab1e8e1b1d7dd105213 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 13 Nov 2020 18:52:02 +0100
+Subject: vfio/pci: Move dummy_resources_list init in vfio_pci_probe()
+
+From: Eric Auger <eric.auger@redhat.com>
+
+[ Upstream commit 16b8fe4caf499ae8e12d2ab1b1324497e36a7b83 ]
+
+In case an error occurs in vfio_pci_enable() before the call to
+vfio_pci_probe_mmaps(), vfio_pci_disable() will try to iterate
+on an uninitialized list and cause a kernel panic.
+
+Lets move to the initialization to vfio_pci_probe() to fix the
+issue.
+
+Signed-off-by: Eric Auger <eric.auger@redhat.com>
+Fixes: 05f0c03fbac1 ("vfio-pci: Allow to mmap sub-page MMIO BARs if the mmio page is exclusive")
+CC: Stable <stable@vger.kernel.org> # v4.7+
+Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/vfio/pci/vfio_pci.c | 3 +--
+ 1 file changed, 1 insertion(+), 2 deletions(-)
+
+diff --git a/drivers/vfio/pci/vfio_pci.c b/drivers/vfio/pci/vfio_pci.c
+index 5e23e4aa5b0a3..c48e1d84efb6b 100644
+--- a/drivers/vfio/pci/vfio_pci.c
++++ b/drivers/vfio/pci/vfio_pci.c
+@@ -118,8 +118,6 @@ static void vfio_pci_probe_mmaps(struct vfio_pci_device *vdev)
+ int bar;
+ struct vfio_pci_dummy_resource *dummy_res;
+
+- INIT_LIST_HEAD(&vdev->dummy_resources_list);
+-
+ for (bar = PCI_STD_RESOURCES; bar <= PCI_STD_RESOURCE_END; bar++) {
+ res = vdev->pdev->resource + bar;
+
+@@ -1522,6 +1520,7 @@ static int vfio_pci_probe(struct pci_dev *pdev, const struct pci_device_id *id)
+ mutex_init(&vdev->igate);
+ spin_lock_init(&vdev->irqlock);
+ mutex_init(&vdev->ioeventfds_lock);
++ INIT_LIST_HEAD(&vdev->dummy_resources_list);
+ INIT_LIST_HEAD(&vdev->ioeventfds_list);
+ mutex_init(&vdev->vma_lock);
+ INIT_LIST_HEAD(&vdev->vma_list);
+--
+2.27.0
+
projects / thirdparty / kernel / stable-queue.git / commitdiff
