From: Greg Kroah-Hartman Date: Mon, 29 Jul 2019 15:58:13 +0000 (+0200) Subject: 4.14-stable patches X-Git-Tag: v5.2.5~19 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=c6036095dbac0ad1a671bf203760ac5a24d0944b;p=thirdparty%2Fkernel%2Fstable-queue.git 4.14-stable patches added patches: btrfs-inode-don-t-compress-if-nodatasum-or-nodatacow-set.patch kvm-nvmx-do-not-use-dangling-shadow-vmcs-after-guest-reset.patch usb-pci-quirks-correct-amd-pll-quirk-detection.patch usb-wusbcore-fix-unbalanced-get-put-cluster_id.patch x86-speculation-mds-apply-more-accurate-check-on-hypervisor-platform.patch x86-sysfb_efi-add-quirks-for-some-devices-with-swapped-width-and-height.patch --- diff --git a/queue-4.14/btrfs-inode-don-t-compress-if-nodatasum-or-nodatacow-set.patch b/queue-4.14/btrfs-inode-don-t-compress-if-nodatasum-or-nodatacow-set.patch new file mode 100644 index 00000000000..5441c6f06ea --- /dev/null +++ b/queue-4.14/btrfs-inode-don-t-compress-if-nodatasum-or-nodatacow-set.patch @@ -0,0 +1,101 @@ +From 42c16da6d684391db83788eb680accd84f6c2083 Mon Sep 17 00:00:00 2001 +From: Qu Wenruo +Date: Mon, 1 Jul 2019 05:12:46 +0000 +Subject: btrfs: inode: Don't compress if NODATASUM or NODATACOW set + +From: Qu Wenruo + +commit 42c16da6d684391db83788eb680accd84f6c2083 upstream. + +As btrfs(5) specified: + + Note + If nodatacow or nodatasum are enabled, compression is disabled. + +If NODATASUM or NODATACOW set, we should not compress the extent. + +Normally NODATACOW is detected properly in run_delalloc_range() so +compression won't happen for NODATACOW. + +However for NODATASUM we don't have any check, and it can cause +compressed extent without csum pretty easily, just by: + mkfs.btrfs -f $dev + mount $dev $mnt -o nodatasum + touch $mnt/foobar + mount -o remount,datasum,compress $mnt + xfs_io -f -c "pwrite 0 128K" $mnt/foobar + +And in fact, we have a bug report about corrupted compressed extent +without proper data checksum so even RAID1 can't recover the corruption. +(https://bugzilla.kernel.org/show_bug.cgi?id=199707) + +Running compression without proper checksum could cause more damage when +corruption happens, as compressed data could make the whole extent +unreadable, so there is no need to allow compression for +NODATACSUM. + +The fix will refactor the inode compression check into two parts: + +- inode_can_compress() + As the hard requirement, checked at btrfs_run_delalloc_range(), so no + compression will happen for NODATASUM inode at all. + +- inode_need_compress() + As the soft requirement, checked at btrfs_run_delalloc_range() and + compress_file_range(). + +Reported-by: James Harvey +CC: stable@vger.kernel.org # 4.4+ +Signed-off-by: Qu Wenruo +Reviewed-by: David Sterba +Signed-off-by: David Sterba +Signed-off-by: Greg Kroah-Hartman + +--- + fs/btrfs/inode.c | 24 +++++++++++++++++++++++- + 1 file changed, 23 insertions(+), 1 deletion(-) + +--- a/fs/btrfs/inode.c ++++ b/fs/btrfs/inode.c +@@ -405,10 +405,31 @@ static noinline int add_async_extent(str + return 0; + } + ++/* ++ * Check if the inode has flags compatible with compression ++ */ ++static inline bool inode_can_compress(struct inode *inode) ++{ ++ if (BTRFS_I(inode)->flags & BTRFS_INODE_NODATACOW || ++ BTRFS_I(inode)->flags & BTRFS_INODE_NODATASUM) ++ return false; ++ return true; ++} ++ ++/* ++ * Check if the inode needs to be submitted to compression, based on mount ++ * options, defragmentation, properties or heuristics. ++ */ + static inline int inode_need_compress(struct inode *inode, u64 start, u64 end) + { + struct btrfs_fs_info *fs_info = btrfs_sb(inode->i_sb); + ++ if (!inode_can_compress(inode)) { ++ WARN(IS_ENABLED(CONFIG_BTRFS_DEBUG), ++ KERN_ERR "BTRFS: unexpected compression for ino %llu\n", ++ btrfs_ino(BTRFS_I(inode))); ++ return 0; ++ } + /* force compress */ + if (btrfs_test_opt(fs_info, FORCE_COMPRESS)) + return 1; +@@ -1626,7 +1647,8 @@ static int run_delalloc_range(void *priv + } else if (BTRFS_I(inode)->flags & BTRFS_INODE_PREALLOC && !force_cow) { + ret = run_delalloc_nocow(inode, locked_page, start, end, + page_started, 0, nr_written); +- } else if (!inode_need_compress(inode, start, end)) { ++ } else if (!inode_can_compress(inode) || ++ !inode_need_compress(inode, start, end)) { + ret = cow_file_range(inode, locked_page, start, end, end, + page_started, nr_written, 1, NULL); + } else { diff --git a/queue-4.14/kvm-nvmx-do-not-use-dangling-shadow-vmcs-after-guest-reset.patch b/queue-4.14/kvm-nvmx-do-not-use-dangling-shadow-vmcs-after-guest-reset.patch new file mode 100644 index 00000000000..b2eeadc525b --- /dev/null +++ b/queue-4.14/kvm-nvmx-do-not-use-dangling-shadow-vmcs-after-guest-reset.patch @@ -0,0 +1,65 @@ +From 967bc679c596ebf41afbb5c9ffc4216354428b6f Mon Sep 17 00:00:00 2001 +From: Paolo Bonzini +Date: Fri, 19 Jul 2019 18:41:10 +0200 +Subject: KVM: nVMX: do not use dangling shadow VMCS after guest reset + +From: Paolo Bonzini + +commit 88dddc11a8d6b09201b4db9d255b3394d9bc9e57 upstream. + +If a KVM guest is reset while running a nested guest, free_nested will +disable the shadow VMCS execution control in the vmcs01. However, +on the next KVM_RUN vmx_vcpu_run would nevertheless try to sync +the VMCS12 to the shadow VMCS which has since been freed. + +This causes a vmptrld of a NULL pointer on my machime, but Jan reports +the host to hang altogether. Let's see how much this trivial patch fixes. + +Reported-by: Jan Kiszka +Cc: Liran Alon +Cc: stable@vger.kernel.org +Signed-off-by: Paolo Bonzini +Signed-off-by: Greg Kroah-Hartman + +--- + arch/x86/kvm/vmx.c | 8 +++++++- + 1 file changed, 7 insertions(+), 1 deletion(-) + +--- a/arch/x86/kvm/vmx.c ++++ b/arch/x86/kvm/vmx.c +@@ -7694,6 +7694,7 @@ static void vmx_disable_shadow_vmcs(stru + { + vmcs_clear_bits(SECONDARY_VM_EXEC_CONTROL, SECONDARY_EXEC_SHADOW_VMCS); + vmcs_write64(VMCS_LINK_POINTER, -1ull); ++ vmx->nested.sync_shadow_vmcs = false; + } + + static inline void nested_release_vmcs12(struct vcpu_vmx *vmx) +@@ -7705,7 +7706,6 @@ static inline void nested_release_vmcs12 + /* copy to memory all shadowed fields in case + they were modified */ + copy_shadow_to_vmcs12(vmx); +- vmx->nested.sync_shadow_vmcs = false; + vmx_disable_shadow_vmcs(vmx); + } + vmx->nested.posted_intr_nv = -1; +@@ -7891,6 +7891,9 @@ static void copy_shadow_to_vmcs12(struct + const unsigned long *fields = shadow_read_write_fields; + const int num_fields = max_shadow_read_write_fields; + ++ if (WARN_ON(!shadow_vmcs)) ++ return; ++ + preempt_disable(); + + vmcs_load(shadow_vmcs); +@@ -7938,6 +7941,9 @@ static void copy_vmcs12_to_shadow(struct + u64 field_value = 0; + struct vmcs *shadow_vmcs = vmx->vmcs01.shadow_vmcs; + ++ if (WARN_ON(!shadow_vmcs)) ++ return; ++ + vmcs_load(shadow_vmcs); + + for (q = 0; q < ARRAY_SIZE(fields); q++) { diff --git a/queue-4.14/series b/queue-4.14/series index bc8a39694c6..f5aaaac4e7c 100644 --- a/queue-4.14/series +++ b/queue-4.14/series @@ -277,3 +277,9 @@ locking-lockdep-fix-lock-used-or-unused-stats-error.patch locking-lockdep-hide-unused-class-variable.patch drm-crc-only-report-a-single-overflow-when-a-crc-fd-.patch drm-crc-debugfs-also-sprinkle-irqrestore-over-early-.patch +usb-wusbcore-fix-unbalanced-get-put-cluster_id.patch +usb-pci-quirks-correct-amd-pll-quirk-detection.patch +kvm-nvmx-do-not-use-dangling-shadow-vmcs-after-guest-reset.patch +btrfs-inode-don-t-compress-if-nodatasum-or-nodatacow-set.patch +x86-sysfb_efi-add-quirks-for-some-devices-with-swapped-width-and-height.patch +x86-speculation-mds-apply-more-accurate-check-on-hypervisor-platform.patch diff --git a/queue-4.14/usb-pci-quirks-correct-amd-pll-quirk-detection.patch b/queue-4.14/usb-pci-quirks-correct-amd-pll-quirk-detection.patch new file mode 100644 index 00000000000..8fd562ccd79 --- /dev/null +++ b/queue-4.14/usb-pci-quirks-correct-amd-pll-quirk-detection.patch @@ -0,0 +1,103 @@ +From f3dccdaade4118070a3a47bef6b18321431f9ac6 Mon Sep 17 00:00:00 2001 +From: Ryan Kennedy +Date: Thu, 4 Jul 2019 11:35:28 -0400 +Subject: usb: pci-quirks: Correct AMD PLL quirk detection + +From: Ryan Kennedy + +commit f3dccdaade4118070a3a47bef6b18321431f9ac6 upstream. + +The AMD PLL USB quirk is incorrectly enabled on newer Ryzen +chipsets. The logic in usb_amd_find_chipset_info currently checks +for unaffected chipsets rather than affected ones. This broke +once a new chipset was added in e788787ef. It makes more sense +to reverse the logic so it won't need to be updated as new +chipsets are added. Note that the core of the workaround in +usb_amd_quirk_pll does correctly check the chipset. + +Signed-off-by: Ryan Kennedy +Fixes: e788787ef4f9 ("usb:xhci:Add quirk for Certain failing HP keyboard on reset after resume") +Cc: stable +Acked-by: Alan Stern +Link: https://lore.kernel.org/r/20190704153529.9429-2-ryan5544@gmail.com +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/usb/host/pci-quirks.c | 31 +++++++++++++++++++------------ + 1 file changed, 19 insertions(+), 12 deletions(-) + +--- a/drivers/usb/host/pci-quirks.c ++++ b/drivers/usb/host/pci-quirks.c +@@ -204,7 +204,7 @@ int usb_amd_find_chipset_info(void) + { + unsigned long flags; + struct amd_chipset_info info; +- int ret; ++ int need_pll_quirk = 0; + + spin_lock_irqsave(&amd_lock, flags); + +@@ -218,21 +218,28 @@ int usb_amd_find_chipset_info(void) + spin_unlock_irqrestore(&amd_lock, flags); + + if (!amd_chipset_sb_type_init(&info)) { +- ret = 0; + goto commit; + } + +- /* Below chipset generations needn't enable AMD PLL quirk */ +- if (info.sb_type.gen == AMD_CHIPSET_UNKNOWN || +- info.sb_type.gen == AMD_CHIPSET_SB600 || +- info.sb_type.gen == AMD_CHIPSET_YANGTZE || +- (info.sb_type.gen == AMD_CHIPSET_SB700 && +- info.sb_type.rev > 0x3b)) { ++ switch (info.sb_type.gen) { ++ case AMD_CHIPSET_SB700: ++ need_pll_quirk = info.sb_type.rev <= 0x3B; ++ break; ++ case AMD_CHIPSET_SB800: ++ case AMD_CHIPSET_HUDSON2: ++ case AMD_CHIPSET_BOLTON: ++ need_pll_quirk = 1; ++ break; ++ default: ++ need_pll_quirk = 0; ++ break; ++ } ++ ++ if (!need_pll_quirk) { + if (info.smbus_dev) { + pci_dev_put(info.smbus_dev); + info.smbus_dev = NULL; + } +- ret = 0; + goto commit; + } + +@@ -251,7 +258,7 @@ int usb_amd_find_chipset_info(void) + } + } + +- ret = info.probe_result = 1; ++ need_pll_quirk = info.probe_result = 1; + printk(KERN_DEBUG "QUIRK: Enable AMD PLL fix\n"); + + commit: +@@ -262,7 +269,7 @@ commit: + + /* Mark that we where here */ + amd_chipset.probe_count++; +- ret = amd_chipset.probe_result; ++ need_pll_quirk = amd_chipset.probe_result; + + spin_unlock_irqrestore(&amd_lock, flags); + +@@ -276,7 +283,7 @@ commit: + spin_unlock_irqrestore(&amd_lock, flags); + } + +- return ret; ++ return need_pll_quirk; + } + EXPORT_SYMBOL_GPL(usb_amd_find_chipset_info); + diff --git a/queue-4.14/usb-wusbcore-fix-unbalanced-get-put-cluster_id.patch b/queue-4.14/usb-wusbcore-fix-unbalanced-get-put-cluster_id.patch new file mode 100644 index 00000000000..ab91c18ee7c --- /dev/null +++ b/queue-4.14/usb-wusbcore-fix-unbalanced-get-put-cluster_id.patch @@ -0,0 +1,61 @@ +From f90bf1ece48a736097ea224430578fe586a9544c Mon Sep 17 00:00:00 2001 +From: Phong Tran +Date: Wed, 24 Jul 2019 09:06:01 +0700 +Subject: usb: wusbcore: fix unbalanced get/put cluster_id + +From: Phong Tran + +commit f90bf1ece48a736097ea224430578fe586a9544c upstream. + +syzboot reported that +https://syzkaller.appspot.com/bug?extid=fd2bd7df88c606eea4ef + +There is not consitency parameter in cluste_id_get/put calling. +In case of getting the id with result is failure, the wusbhc->cluster_id +will not be updated and this can not be used for wusb_cluster_id_put(). + +Tested report +https://groups.google.com/d/msg/syzkaller-bugs/0znZopp3-9k/oxOrhLkLEgAJ + +Reproduce and gdb got the details: + +139 addr = wusb_cluster_id_get(); +(gdb) n +140 if (addr == 0) +(gdb) print addr +$1 = 254 '\376' +(gdb) n +142 result = __hwahc_set_cluster_id(hwahc, addr); +(gdb) print result +$2 = -71 +(gdb) break wusb_cluster_id_put +Breakpoint 3 at 0xffffffff836e3f20: file drivers/usb/wusbcore/wusbhc.c, line 384. +(gdb) s +Thread 2 hit Breakpoint 3, wusb_cluster_id_put (id=0 '\000') at drivers/usb/wusbcore/wusbhc.c:384 +384 id = 0xff - id; +(gdb) n +385 BUG_ON(id >= CLUSTER_IDS); +(gdb) print id +$3 = 255 '\377' + +Reported-by: syzbot+fd2bd7df88c606eea4ef@syzkaller.appspotmail.com +Signed-off-by: Phong Tran +Cc: stable +Link: https://lore.kernel.org/r/20190724020601.15257-1-tranmanphong@gmail.com +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/usb/host/hwa-hc.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/usb/host/hwa-hc.c ++++ b/drivers/usb/host/hwa-hc.c +@@ -173,7 +173,7 @@ out: + return result; + + error_set_cluster_id: +- wusb_cluster_id_put(wusbhc->cluster_id); ++ wusb_cluster_id_put(addr); + error_cluster_id_get: + goto out; + diff --git a/queue-4.14/x86-speculation-mds-apply-more-accurate-check-on-hypervisor-platform.patch b/queue-4.14/x86-speculation-mds-apply-more-accurate-check-on-hypervisor-platform.patch new file mode 100644 index 00000000000..849482ab44f --- /dev/null +++ b/queue-4.14/x86-speculation-mds-apply-more-accurate-check-on-hypervisor-platform.patch @@ -0,0 +1,41 @@ +From 517c3ba00916383af6411aec99442c307c23f684 Mon Sep 17 00:00:00 2001 +From: Zhenzhong Duan +Date: Thu, 25 Jul 2019 10:39:09 +0800 +Subject: x86/speculation/mds: Apply more accurate check on hypervisor platform + +From: Zhenzhong Duan + +commit 517c3ba00916383af6411aec99442c307c23f684 upstream. + +X86_HYPER_NATIVE isn't accurate for checking if running on native platform, +e.g. CONFIG_HYPERVISOR_GUEST isn't set or "nopv" is enabled. + +Checking the CPU feature bit X86_FEATURE_HYPERVISOR to determine if it's +running on native platform is more accurate. + +This still doesn't cover the platforms on which X86_FEATURE_HYPERVISOR is +unsupported, e.g. VMware, but there is nothing which can be done about this +scenario. + +Fixes: 8a4b06d391b0 ("x86/speculation/mds: Add sysfs reporting for MDS") +Signed-off-by: Zhenzhong Duan +Signed-off-by: Thomas Gleixner +Cc: stable@vger.kernel.org +Link: https://lkml.kernel.org/r/1564022349-17338-1-git-send-email-zhenzhong.duan@oracle.com +Signed-off-by: Greg Kroah-Hartman + +--- + arch/x86/kernel/cpu/bugs.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/arch/x86/kernel/cpu/bugs.c ++++ b/arch/x86/kernel/cpu/bugs.c +@@ -1196,7 +1196,7 @@ static ssize_t l1tf_show_state(char *buf + + static ssize_t mds_show_state(char *buf) + { +- if (!hypervisor_is_type(X86_HYPER_NATIVE)) { ++ if (boot_cpu_has(X86_FEATURE_HYPERVISOR)) { + return sprintf(buf, "%s; SMT Host state unknown\n", + mds_strings[mds_mitigation]); + } diff --git a/queue-4.14/x86-sysfb_efi-add-quirks-for-some-devices-with-swapped-width-and-height.patch b/queue-4.14/x86-sysfb_efi-add-quirks-for-some-devices-with-swapped-width-and-height.patch new file mode 100644 index 00000000000..df9876a0005 --- /dev/null +++ b/queue-4.14/x86-sysfb_efi-add-quirks-for-some-devices-with-swapped-width-and-height.patch @@ -0,0 +1,91 @@ +From d02f1aa39189e0619c3525d5cd03254e61bf606a Mon Sep 17 00:00:00 2001 +From: Hans de Goede +Date: Sun, 21 Jul 2019 17:24:18 +0200 +Subject: x86/sysfb_efi: Add quirks for some devices with swapped width and height + +From: Hans de Goede + +commit d02f1aa39189e0619c3525d5cd03254e61bf606a upstream. + +Some Lenovo 2-in-1s with a detachable keyboard have a portrait screen but +advertise a landscape resolution and pitch, resulting in a messed up +display if the kernel tries to show anything on the efifb (because of the +wrong pitch). + +Fix this by adding a new DMI match table for devices which need to have +their width and height swapped. + +At first it was tried to use the existing table for overriding some of the +efifb parameters, but some of the affected devices have variants with +different LCD resolutions which will not work with hardcoded override +values. + +Reference: https://bugzilla.redhat.com/show_bug.cgi?id=1730783 +Signed-off-by: Hans de Goede +Signed-off-by: Thomas Gleixner +Cc: stable@vger.kernel.org +Link: https://lkml.kernel.org/r/20190721152418.11644-1-hdegoede@redhat.com +Signed-off-by: Greg Kroah-Hartman + +--- + arch/x86/kernel/sysfb_efi.c | 46 ++++++++++++++++++++++++++++++++++++++++++++ + 1 file changed, 46 insertions(+) + +--- a/arch/x86/kernel/sysfb_efi.c ++++ b/arch/x86/kernel/sysfb_efi.c +@@ -231,9 +231,55 @@ static const struct dmi_system_id efifb_ + {}, + }; + ++/* ++ * Some devices have a portrait LCD but advertise a landscape resolution (and ++ * pitch). We simply swap width and height for these devices so that we can ++ * correctly deal with some of them coming with multiple resolutions. ++ */ ++static const struct dmi_system_id efifb_dmi_swap_width_height[] __initconst = { ++ { ++ /* ++ * Lenovo MIIX310-10ICR, only some batches have the troublesome ++ * 800x1280 portrait screen. Luckily the portrait version has ++ * its own BIOS version, so we match on that. ++ */ ++ .matches = { ++ DMI_EXACT_MATCH(DMI_SYS_VENDOR, "LENOVO"), ++ DMI_EXACT_MATCH(DMI_PRODUCT_VERSION, "MIIX 310-10ICR"), ++ DMI_EXACT_MATCH(DMI_BIOS_VERSION, "1HCN44WW"), ++ }, ++ }, ++ { ++ /* Lenovo MIIX 320-10ICR with 800x1280 portrait screen */ ++ .matches = { ++ DMI_EXACT_MATCH(DMI_SYS_VENDOR, "LENOVO"), ++ DMI_EXACT_MATCH(DMI_PRODUCT_VERSION, ++ "Lenovo MIIX 320-10ICR"), ++ }, ++ }, ++ { ++ /* Lenovo D330 with 800x1280 or 1200x1920 portrait screen */ ++ .matches = { ++ DMI_EXACT_MATCH(DMI_SYS_VENDOR, "LENOVO"), ++ DMI_EXACT_MATCH(DMI_PRODUCT_VERSION, ++ "Lenovo ideapad D330-10IGM"), ++ }, ++ }, ++ {}, ++}; ++ + __init void sysfb_apply_efi_quirks(void) + { + if (screen_info.orig_video_isVGA != VIDEO_TYPE_EFI || + !(screen_info.capabilities & VIDEO_CAPABILITY_SKIP_QUIRKS)) + dmi_check_system(efifb_dmi_system_table); ++ ++ if (screen_info.orig_video_isVGA == VIDEO_TYPE_EFI && ++ dmi_check_system(efifb_dmi_swap_width_height)) { ++ u16 temp = screen_info.lfb_width; ++ ++ screen_info.lfb_width = screen_info.lfb_height; ++ screen_info.lfb_height = temp; ++ screen_info.lfb_linelength = 4 * screen_info.lfb_width; ++ } + }