--- /dev/null
+From 8e138e0d92c6c9d3d481674fb14e3439b495be37 Mon Sep 17 00:00:00 2001
+From: Josef Bacik <jbacik@fb.com>
+Date: Fri, 17 Nov 2017 14:50:46 -0500
+Subject: btrfs: clear space cache inode generation always
+
+From: Josef Bacik <jbacik@fb.com>
+
+commit 8e138e0d92c6c9d3d481674fb14e3439b495be37 upstream.
+
+We discovered a box that had double allocations, and suspected the space
+cache may be to blame. While auditing the write out path I noticed that
+if we've already setup the space cache we will just carry on. This
+means that any error we hit after cache_save_setup before we go to
+actually write the cache out we won't reset the inode generation, so
+whatever was already written will be considered correct, except it'll be
+stale. Fix this by _always_ resetting the generation on the block group
+inode, this way we only ever have valid or invalid cache.
+
+With this patch I was no longer able to reproduce cache corruption with
+dm-log-writes and my bpf error injection tool.
+
+Signed-off-by: Josef Bacik <jbacik@fb.com>
+Signed-off-by: David Sterba <dsterba@suse.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/btrfs/extent-tree.c | 14 +++++++-------
+ 1 file changed, 7 insertions(+), 7 deletions(-)
+
+--- a/fs/btrfs/extent-tree.c
++++ b/fs/btrfs/extent-tree.c
+@@ -3361,13 +3361,6 @@ again:
+ goto again;
+ }
+
+- /* We've already setup this transaction, go ahead and exit */
+- if (block_group->cache_generation == trans->transid &&
+- i_size_read(inode)) {
+- dcs = BTRFS_DC_SETUP;
+- goto out_put;
+- }
+-
+ /*
+ * We want to set the generation to 0, that way if anything goes wrong
+ * from here on out we know not to trust this cache when we load up next
+@@ -3391,6 +3384,13 @@ again:
+ }
+ WARN_ON(ret);
+
++ /* We've already setup this transaction, go ahead and exit */
++ if (block_group->cache_generation == trans->transid &&
++ i_size_read(inode)) {
++ dcs = BTRFS_DC_SETUP;
++ goto out_put;
++ }
++
+ if (i_size_read(inode) > 0) {
+ ret = btrfs_check_trunc_cache_free_space(root,
+ &root->fs_info->global_block_rsv);
--- /dev/null
+From 61cb57c9ed631c95b54f8e9090c89d18b3695b3c Mon Sep 17 00:00:00 2001
+From: Liran Alon <liran.alon@oracle.com>
+Date: Sun, 5 Nov 2017 16:56:32 +0200
+Subject: KVM: x86: Exit to user-mode on #UD intercept when emulator requires
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Liran Alon <liran.alon@oracle.com>
+
+commit 61cb57c9ed631c95b54f8e9090c89d18b3695b3c upstream.
+
+Instruction emulation after trapping a #UD exception can result in an
+MMIO access, for example when emulating a MOVBE on a processor that
+doesn't support the instruction. In this case, the #UD vmexit handler
+must exit to user mode, but there wasn't any code to do so. Add it for
+both VMX and SVM.
+
+Signed-off-by: Liran Alon <liran.alon@oracle.com>
+Reviewed-by: Nikita Leshenko <nikita.leshchenko@oracle.com>
+Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
+Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
+Reviewed-by: Wanpeng Li <wanpeng.li@hotmail.com>
+Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
+Signed-off-by: Radim Krčmář <rkrcmar@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/x86/kvm/svm.c | 2 ++
+ arch/x86/kvm/vmx.c | 2 ++
+ 2 files changed, 4 insertions(+)
+
+--- a/arch/x86/kvm/svm.c
++++ b/arch/x86/kvm/svm.c
+@@ -1696,6 +1696,8 @@ static int ud_interception(struct vcpu_s
+ int er;
+
+ er = emulate_instruction(&svm->vcpu, EMULTYPE_TRAP_UD);
++ if (er == EMULATE_USER_EXIT)
++ return 0;
+ if (er != EMULATE_DONE)
+ kvm_queue_exception(&svm->vcpu, UD_VECTOR);
+ return 1;
+--- a/arch/x86/kvm/vmx.c
++++ b/arch/x86/kvm/vmx.c
+@@ -5267,6 +5267,8 @@ static int handle_exception(struct kvm_v
+ return 1;
+ }
+ er = emulate_instruction(vcpu, EMULTYPE_TRAP_UD);
++ if (er == EMULATE_USER_EXIT)
++ return 0;
+ if (er != EMULATE_DONE)
+ kvm_queue_exception(vcpu, UD_VECTOR);
+ return 1;
--- /dev/null
+From 6ea6e84309ca7e0e850b3083e6b09344ee15c290 Mon Sep 17 00:00:00 2001
+From: Paolo Bonzini <pbonzini@redhat.com>
+Date: Fri, 10 Nov 2017 10:49:38 +0100
+Subject: KVM: x86: inject exceptions produced by x86_decode_insn
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Paolo Bonzini <pbonzini@redhat.com>
+
+commit 6ea6e84309ca7e0e850b3083e6b09344ee15c290 upstream.
+
+Sometimes, a processor might execute an instruction while another
+processor is updating the page tables for that instruction's code page,
+but before the TLB shootdown completes. The interesting case happens
+if the page is in the TLB.
+
+In general, the processor will succeed in executing the instruction and
+nothing bad happens. However, what if the instruction is an MMIO access?
+If *that* happens, KVM invokes the emulator, and the emulator gets the
+updated page tables. If the update side had marked the code page as non
+present, the page table walk then will fail and so will x86_decode_insn.
+
+Unfortunately, even though kvm_fetch_guest_virt is correctly returning
+X86EMUL_PROPAGATE_FAULT, x86_decode_insn's caller treats the failure as
+a fatal error if the instruction cannot simply be reexecuted (as is the
+case for MMIO). And this in fact happened sometimes when rebooting
+Windows 2012r2 guests. Just checking ctxt->have_exception and injecting
+the exception if true is enough to fix the case.
+
+Thanks to Eduardo Habkost for helping in the debugging of this issue.
+
+Reported-by: Yanan Fu <yfu@redhat.com>
+Cc: Eduardo Habkost <ehabkost@redhat.com>
+Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
+Signed-off-by: Radim Krčmář <rkrcmar@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/x86/kvm/x86.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/arch/x86/kvm/x86.c
++++ b/arch/x86/kvm/x86.c
+@@ -5429,6 +5429,8 @@ int x86_emulate_instruction(struct kvm_v
+ if (reexecute_instruction(vcpu, cr2, write_fault_to_spt,
+ emulation_type))
+ return EMULATE_DONE;
++ if (ctxt->have_exception && inject_emulated_exception(vcpu))
++ return EMULATE_DONE;
+ if (emulation_type & EMULTYPE_SKIP)
+ return EMULATE_FAIL;
+ return handle_emulation_failure(vcpu);
--- /dev/null
+From 51c4b8bba674cfd2260d173602c4dac08e4c3a99 Mon Sep 17 00:00:00 2001
+From: Liran Alon <liran.alon@oracle.com>
+Date: Sun, 5 Nov 2017 16:11:30 +0200
+Subject: KVM: x86: pvclock: Handle first-time write to pvclock-page contains random junk
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Liran Alon <liran.alon@oracle.com>
+
+commit 51c4b8bba674cfd2260d173602c4dac08e4c3a99 upstream.
+
+When guest passes KVM it's pvclock-page GPA via WRMSR to
+MSR_KVM_SYSTEM_TIME / MSR_KVM_SYSTEM_TIME_NEW, KVM don't initialize
+pvclock-page to some start-values. It just requests a clock-update which
+will happen before entering to guest.
+
+The clock-update logic will call kvm_setup_pvclock_page() to update the
+pvclock-page with info. However, kvm_setup_pvclock_page() *wrongly*
+assumes that the version-field is initialized to an even number. This is
+wrong because at first-time write, field could be any-value.
+
+Fix simply makes sure that if first-time version-field is odd, increment
+it once more to make it even and only then start standard logic.
+This follows same logic as done in other pvclock shared-pages (See
+kvm_write_wall_clock() and record_steal_time()).
+
+Signed-off-by: Liran Alon <liran.alon@oracle.com>
+Reviewed-by: Nikita Leshenko <nikita.leshchenko@oracle.com>
+Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
+Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
+Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
+Signed-off-by: Radim Krčmář <rkrcmar@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/x86/kvm/x86.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+--- a/arch/x86/kvm/x86.c
++++ b/arch/x86/kvm/x86.c
+@@ -1812,6 +1812,9 @@ static int kvm_guest_time_update(struct
+ */
+ BUILD_BUG_ON(offsetof(struct pvclock_vcpu_time_info, version) != 0);
+
++ if (guest_hv_clock.version & 1)
++ ++guest_hv_clock.version; /* first time write, random junk */
++
+ vcpu->hv_clock.version = guest_hv_clock.version + 1;
+ kvm_write_guest_cached(v->kvm, &vcpu->pv_time,
+ &vcpu->hv_clock,
--- /dev/null
+From ebe7dd45cf49e3b49cacbaace17f9f878f21fbea Mon Sep 17 00:00:00 2001
+From: Adrian Hunter <adrian.hunter@intel.com>
+Date: Tue, 21 Nov 2017 15:42:29 +0200
+Subject: mmc: core: Do not leave the block driver in a suspended state
+
+From: Adrian Hunter <adrian.hunter@intel.com>
+
+commit ebe7dd45cf49e3b49cacbaace17f9f878f21fbea upstream.
+
+The block driver must be resumed if the mmc bus fails to suspend the card.
+
+Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
+Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
+Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/mmc/core/bus.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+--- a/drivers/mmc/core/bus.c
++++ b/drivers/mmc/core/bus.c
+@@ -155,6 +155,9 @@ static int mmc_bus_suspend(struct device
+ return ret;
+
+ ret = host->bus_ops->suspend(host);
++ if (ret)
++ pm_generic_resume(dev);
++
+ return ret;
+ }
+
x86-efi-bgrt-replace-early_memremap-with-memremap.patch
mm-thp-do-not-make-page-table-dirty-unconditionally-in-touch_pd.patch
mm-madvise.c-fix-madvise-infinite-loop-under-special-circumstances.patch
+btrfs-clear-space-cache-inode-generation-always.patch
+kvm-x86-pvclock-handle-first-time-write-to-pvclock-page-contains-random-junk.patch
+kvm-x86-exit-to-user-mode-on-ud-intercept-when-emulator-requires.patch
+kvm-x86-inject-exceptions-produced-by-x86_decode_insn.patch
+mmc-core-do-not-leave-the-block-driver-in-a-suspended-state.patch
projects / thirdparty / kernel / stable-queue.git / commitdiff
