From 1cc97dc1c0bf94110c449b8148d94e86b35714b3 Mon Sep 17 00:00:00 2001 From: Greg Kroah-Hartman Date: Mon, 4 Dec 2017 10:32:55 +0100 Subject: [PATCH] 4.4-stable patches added patches: btrfs-clear-space-cache-inode-generation-always.patch kvm-x86-exit-to-user-mode-on-ud-intercept-when-emulator-requires.patch kvm-x86-inject-exceptions-produced-by-x86_decode_insn.patch kvm-x86-pvclock-handle-first-time-write-to-pvclock-page-contains-random-junk.patch mmc-core-do-not-leave-the-block-driver-in-a-suspended-state.patch --- ...-space-cache-inode-generation-always.patch | 59 +++++++++++++++++++ ...-ud-intercept-when-emulator-requires.patch | 54 +++++++++++++++++ ...ceptions-produced-by-x86_decode_insn.patch | 53 +++++++++++++++++ ...to-pvclock-page-contains-random-junk.patch | 51 ++++++++++++++++ ...he-block-driver-in-a-suspended-state.patch | 32 ++++++++++ queue-4.4/series | 5 ++ 6 files changed, 254 insertions(+) create mode 100644 queue-4.4/btrfs-clear-space-cache-inode-generation-always.patch create mode 100644 queue-4.4/kvm-x86-exit-to-user-mode-on-ud-intercept-when-emulator-requires.patch create mode 100644 queue-4.4/kvm-x86-inject-exceptions-produced-by-x86_decode_insn.patch create mode 100644 queue-4.4/kvm-x86-pvclock-handle-first-time-write-to-pvclock-page-contains-random-junk.patch create mode 100644 queue-4.4/mmc-core-do-not-leave-the-block-driver-in-a-suspended-state.patch diff --git a/queue-4.4/btrfs-clear-space-cache-inode-generation-always.patch b/queue-4.4/btrfs-clear-space-cache-inode-generation-always.patch new file mode 100644 index 00000000000..138ae4a037d --- /dev/null +++ b/queue-4.4/btrfs-clear-space-cache-inode-generation-always.patch @@ -0,0 +1,59 @@ +From 8e138e0d92c6c9d3d481674fb14e3439b495be37 Mon Sep 17 00:00:00 2001 +From: Josef Bacik +Date: Fri, 17 Nov 2017 14:50:46 -0500 +Subject: btrfs: clear space cache inode generation always + +From: Josef Bacik + +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 +Signed-off-by: David Sterba +Signed-off-by: Greg Kroah-Hartman + +--- + 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); diff --git a/queue-4.4/kvm-x86-exit-to-user-mode-on-ud-intercept-when-emulator-requires.patch b/queue-4.4/kvm-x86-exit-to-user-mode-on-ud-intercept-when-emulator-requires.patch new file mode 100644 index 00000000000..c22b5fd6697 --- /dev/null +++ b/queue-4.4/kvm-x86-exit-to-user-mode-on-ud-intercept-when-emulator-requires.patch @@ -0,0 +1,54 @@ +From 61cb57c9ed631c95b54f8e9090c89d18b3695b3c Mon Sep 17 00:00:00 2001 +From: Liran Alon +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 + +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 +Reviewed-by: Nikita Leshenko +Reviewed-by: Konrad Rzeszutek Wilk +Signed-off-by: Konrad Rzeszutek Wilk +Reviewed-by: Wanpeng Li +Reviewed-by: Paolo Bonzini +Signed-off-by: Radim Krčmář +Signed-off-by: Greg Kroah-Hartman + +--- + 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; diff --git a/queue-4.4/kvm-x86-inject-exceptions-produced-by-x86_decode_insn.patch b/queue-4.4/kvm-x86-inject-exceptions-produced-by-x86_decode_insn.patch new file mode 100644 index 00000000000..91b4ad141cb --- /dev/null +++ b/queue-4.4/kvm-x86-inject-exceptions-produced-by-x86_decode_insn.patch @@ -0,0 +1,53 @@ +From 6ea6e84309ca7e0e850b3083e6b09344ee15c290 Mon Sep 17 00:00:00 2001 +From: Paolo Bonzini +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 + +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 +Cc: Eduardo Habkost +Signed-off-by: Paolo Bonzini +Signed-off-by: Radim Krčmář +Signed-off-by: Greg Kroah-Hartman + +--- + 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); diff --git a/queue-4.4/kvm-x86-pvclock-handle-first-time-write-to-pvclock-page-contains-random-junk.patch b/queue-4.4/kvm-x86-pvclock-handle-first-time-write-to-pvclock-page-contains-random-junk.patch new file mode 100644 index 00000000000..13d8132f6cc --- /dev/null +++ b/queue-4.4/kvm-x86-pvclock-handle-first-time-write-to-pvclock-page-contains-random-junk.patch @@ -0,0 +1,51 @@ +From 51c4b8bba674cfd2260d173602c4dac08e4c3a99 Mon Sep 17 00:00:00 2001 +From: Liran Alon +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 + +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 +Reviewed-by: Nikita Leshenko +Reviewed-by: Konrad Rzeszutek Wilk +Signed-off-by: Konrad Rzeszutek Wilk +Reviewed-by: Paolo Bonzini +Signed-off-by: Radim Krčmář +Signed-off-by: Greg Kroah-Hartman + +--- + 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, diff --git a/queue-4.4/mmc-core-do-not-leave-the-block-driver-in-a-suspended-state.patch b/queue-4.4/mmc-core-do-not-leave-the-block-driver-in-a-suspended-state.patch new file mode 100644 index 00000000000..3d124617415 --- /dev/null +++ b/queue-4.4/mmc-core-do-not-leave-the-block-driver-in-a-suspended-state.patch @@ -0,0 +1,32 @@ +From ebe7dd45cf49e3b49cacbaace17f9f878f21fbea Mon Sep 17 00:00:00 2001 +From: Adrian Hunter +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 + +commit ebe7dd45cf49e3b49cacbaace17f9f878f21fbea upstream. + +The block driver must be resumed if the mmc bus fails to suspend the card. + +Signed-off-by: Adrian Hunter +Reviewed-by: Linus Walleij +Signed-off-by: Ulf Hansson +Signed-off-by: Greg Kroah-Hartman + +--- + 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; + } + diff --git a/queue-4.4/series b/queue-4.4/series index 21264a7afbb..8a6d376702f 100644 --- a/queue-4.4/series +++ b/queue-4.4/series @@ -8,3 +8,8 @@ x86-efi-bgrt-fix-kernel-panic-when-mapping-bgrt-data.patch 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 -- 2.47.3