From: Greg Kroah-Hartman Date: Mon, 14 Dec 2020 14:48:39 +0000 (+0100) Subject: 5.4-stable patches X-Git-Tag: v5.10.1~14 X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=7fa7b1b5d6f6574ad58e56b830a96264ef2b9767;p=thirdparty%2Fkernel%2Fstable-queue.git 5.4-stable patches added patches: drm-i915-display-dp-compute-the-correct-slice-count-for-vdsc-on-dp.patch input-cm109-do-not-stomp-on-control-urb.patch input-i8042-add-acer-laptops-to-the-i8042-reset-list.patch kbuild-avoid-static_assert-for-genksyms.patch ktest.pl-fix-incorrect-reboot-for-grub2bls.patch mmc-block-fixup-condition-for-cmd13-polling-for-rpmb-requests.patch pinctrl-amd-remove-debounce-filter-setting-in-irq-type-setting.patch proc-use-untagged_addr-for-pagemap_read-addresses.patch scsi-be2iscsi-revert-fix-a-theoretical-leak-in-beiscsi_create_eqs.patch x86-apic-vector-fix-ordering-in-vector-assignment.patch x86-membarrier-get-rid-of-a-dubious-optimization.patch x86-mm-mem_encrypt-fix-definition-of-pmd_flags_dec_wp.patch --- diff --git a/queue-5.4/drm-i915-display-dp-compute-the-correct-slice-count-for-vdsc-on-dp.patch b/queue-5.4/drm-i915-display-dp-compute-the-correct-slice-count-for-vdsc-on-dp.patch new file mode 100644 index 00000000000..da96143e2e3 --- /dev/null +++ b/queue-5.4/drm-i915-display-dp-compute-the-correct-slice-count-for-vdsc-on-dp.patch @@ -0,0 +1,46 @@ +From f6cbe49be65ed800863ac5ba695555057363f9c2 Mon Sep 17 00:00:00 2001 +From: Manasi Navare +Date: Fri, 4 Dec 2020 12:58:04 -0800 +Subject: drm/i915/display/dp: Compute the correct slice count for VDSC on DP + +From: Manasi Navare + +commit f6cbe49be65ed800863ac5ba695555057363f9c2 upstream. + +This patch fixes the slice count computation algorithm +for calculating the slice count based on Peak pixel rate +and the max slice width allowed on the DSC engines. +We need to ensure slice count > min slice count req +as per DP spec based on peak pixel rate and that it is +greater than min slice count based on the max slice width +advertised by DPCD. So use max of these two. +In the prev patch we were using min of these 2 causing it +to violate the max slice width limitation causing a blank +screen on 8K@60. + +Fixes: d9218c8f6cf4 ("drm/i915/dp: Add helpers for Compressed BPP and Slice Count for DSC") +Cc: Ankit Nautiyal +Cc: Jani Nikula +Cc: # v5.0+ +Signed-off-by: Manasi Navare +Reviewed-by: Ankit Nautiyal +Link: https://patchwork.freedesktop.org/patch/msgid/20201204205804.25225-1-manasi.d.navare@intel.com +(cherry picked from commit d371d6ea92ad2a47f42bbcaa786ee5f6069c9c14) +Signed-off-by: Rodrigo Vivi +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/gpu/drm/i915/display/intel_dp.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/gpu/drm/i915/display/intel_dp.c ++++ b/drivers/gpu/drm/i915/display/intel_dp.c +@@ -567,7 +567,7 @@ static u8 intel_dp_dsc_get_slice_count(s + return 0; + } + /* Also take into account max slice width */ +- min_slice_count = min_t(u8, min_slice_count, ++ min_slice_count = max_t(u8, min_slice_count, + DIV_ROUND_UP(mode_hdisplay, + max_slice_width)); + diff --git a/queue-5.4/input-cm109-do-not-stomp-on-control-urb.patch b/queue-5.4/input-cm109-do-not-stomp-on-control-urb.patch new file mode 100644 index 00000000000..5ac5ef7ff72 --- /dev/null +++ b/queue-5.4/input-cm109-do-not-stomp-on-control-urb.patch @@ -0,0 +1,42 @@ +From 82e06090473289ce63e23fdeb8737aad59b10645 Mon Sep 17 00:00:00 2001 +From: Dmitry Torokhov +Date: Wed, 9 Dec 2020 20:13:24 -0800 +Subject: Input: cm109 - do not stomp on control URB + +From: Dmitry Torokhov + +commit 82e06090473289ce63e23fdeb8737aad59b10645 upstream. + +We need to make sure we are not stomping on the control URB that was +issued when opening the device when attempting to toggle buzzer. +To do that we need to mark it as pending in cm109_open(). + +Reported-and-tested-by: syzbot+150f793ac5bc18eee150@syzkaller.appspotmail.com +Cc: stable@vger.kernel.org +Signed-off-by: Dmitry Torokhov +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/input/misc/cm109.c | 7 +++++-- + 1 file changed, 5 insertions(+), 2 deletions(-) + +--- a/drivers/input/misc/cm109.c ++++ b/drivers/input/misc/cm109.c +@@ -568,12 +568,15 @@ static int cm109_input_open(struct input + dev->ctl_data->byte[HID_OR2] = dev->keybit; + dev->ctl_data->byte[HID_OR3] = 0x00; + ++ dev->ctl_urb_pending = 1; + error = usb_submit_urb(dev->urb_ctl, GFP_KERNEL); +- if (error) ++ if (error) { ++ dev->ctl_urb_pending = 0; + dev_err(&dev->intf->dev, "%s: usb_submit_urb (urb_ctl) failed %d\n", + __func__, error); +- else ++ } else { + dev->open = 1; ++ } + + mutex_unlock(&dev->pm_mutex); + diff --git a/queue-5.4/input-i8042-add-acer-laptops-to-the-i8042-reset-list.patch b/queue-5.4/input-i8042-add-acer-laptops-to-the-i8042-reset-list.patch new file mode 100644 index 00000000000..c38d34fb692 --- /dev/null +++ b/queue-5.4/input-i8042-add-acer-laptops-to-the-i8042-reset-list.patch @@ -0,0 +1,74 @@ +From ce6520b0eafad5962ffc21dc47cd7bd3250e9045 Mon Sep 17 00:00:00 2001 +From: Chris Chiu +Date: Wed, 9 Dec 2020 20:24:47 -0800 +Subject: Input: i8042 - add Acer laptops to the i8042 reset list + +From: Chris Chiu + +commit ce6520b0eafad5962ffc21dc47cd7bd3250e9045 upstream. + +The touchpad operates in Basic Mode by default in the Acer BIOS +setup, but some Aspire/TravelMate models require the i8042 to be +reset in order to be correctly detected. + +Signed-off-by: Chris Chiu +Link: https://lore.kernel.org/r/20201207071250.15021-1-chiu@endlessos.org +Cc: stable@vger.kernel.org +Signed-off-by: Dmitry Torokhov +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/input/serio/i8042-x86ia64io.h | 42 ++++++++++++++++++++++++++++++++++ + 1 file changed, 42 insertions(+) + +--- a/drivers/input/serio/i8042-x86ia64io.h ++++ b/drivers/input/serio/i8042-x86ia64io.h +@@ -612,6 +612,48 @@ static const struct dmi_system_id __init + }, + }, + { ++ .matches = { ++ DMI_MATCH(DMI_SYS_VENDOR, "Acer"), ++ DMI_MATCH(DMI_PRODUCT_NAME, "Aspire A114-31"), ++ }, ++ }, ++ { ++ .matches = { ++ DMI_MATCH(DMI_SYS_VENDOR, "Acer"), ++ DMI_MATCH(DMI_PRODUCT_NAME, "Aspire A314-31"), ++ }, ++ }, ++ { ++ .matches = { ++ DMI_MATCH(DMI_SYS_VENDOR, "Acer"), ++ DMI_MATCH(DMI_PRODUCT_NAME, "Aspire A315-31"), ++ }, ++ }, ++ { ++ .matches = { ++ DMI_MATCH(DMI_SYS_VENDOR, "Acer"), ++ DMI_MATCH(DMI_PRODUCT_NAME, "Aspire ES1-132"), ++ }, ++ }, ++ { ++ .matches = { ++ DMI_MATCH(DMI_SYS_VENDOR, "Acer"), ++ DMI_MATCH(DMI_PRODUCT_NAME, "Aspire ES1-332"), ++ }, ++ }, ++ { ++ .matches = { ++ DMI_MATCH(DMI_SYS_VENDOR, "Acer"), ++ DMI_MATCH(DMI_PRODUCT_NAME, "Aspire ES1-432"), ++ }, ++ }, ++ { ++ .matches = { ++ DMI_MATCH(DMI_SYS_VENDOR, "Acer"), ++ DMI_MATCH(DMI_PRODUCT_NAME, "TravelMate Spin B118-RN"), ++ }, ++ }, ++ { + /* Advent 4211 */ + .matches = { + DMI_MATCH(DMI_SYS_VENDOR, "DIXONSXP"), diff --git a/queue-5.4/kbuild-avoid-static_assert-for-genksyms.patch b/queue-5.4/kbuild-avoid-static_assert-for-genksyms.patch new file mode 100644 index 00000000000..032aa9b2aef --- /dev/null +++ b/queue-5.4/kbuild-avoid-static_assert-for-genksyms.patch @@ -0,0 +1,48 @@ +From 14dc3983b5dff513a90bd5a8cc90acaf7867c3d0 Mon Sep 17 00:00:00 2001 +From: Arnd Bergmann +Date: Fri, 11 Dec 2020 13:36:38 -0800 +Subject: kbuild: avoid static_assert for genksyms + +From: Arnd Bergmann + +commit 14dc3983b5dff513a90bd5a8cc90acaf7867c3d0 upstream. + +genksyms does not know or care about the _Static_assert() built-in, and +sometimes falls back to ignoring the later symbols, which causes +undefined behavior such as + + WARNING: modpost: EXPORT symbol "ethtool_set_ethtool_phy_ops" [vmlinux] version generation failed, symbol will not be versioned. + ld: net/ethtool/common.o: relocation R_AARCH64_ABS32 against `__crc_ethtool_set_ethtool_phy_ops' can not be used when making a shared object + net/ethtool/common.o:(_ftrace_annotated_branch+0x0): dangerous relocation: unsupported relocation + +Redefine static_assert for genksyms to avoid that. + +Link: https://lkml.kernel.org/r/20201203230955.1482058-1-arnd@kernel.org +Signed-off-by: Arnd Bergmann +Suggested-by: Ard Biesheuvel +Cc: Masahiro Yamada +Cc: Michal Marek +Cc: Kees Cook +Cc: Rikard Falkeborn +Cc: Marco Elver +Cc: +Signed-off-by: Andrew Morton +Signed-off-by: Linus Torvalds +Signed-off-by: Greg Kroah-Hartman + +--- + include/linux/build_bug.h | 5 +++++ + 1 file changed, 5 insertions(+) + +--- a/include/linux/build_bug.h ++++ b/include/linux/build_bug.h +@@ -77,4 +77,9 @@ + #define static_assert(expr, ...) __static_assert(expr, ##__VA_ARGS__, #expr) + #define __static_assert(expr, msg, ...) _Static_assert(expr, msg) + ++#ifdef __GENKSYMS__ ++/* genksyms gets confused by _Static_assert */ ++#define _Static_assert(expr, ...) ++#endif ++ + #endif /* _LINUX_BUILD_BUG_H */ diff --git a/queue-5.4/ktest.pl-fix-incorrect-reboot-for-grub2bls.patch b/queue-5.4/ktest.pl-fix-incorrect-reboot-for-grub2bls.patch new file mode 100644 index 00000000000..60bc34d8d86 --- /dev/null +++ b/queue-5.4/ktest.pl-fix-incorrect-reboot-for-grub2bls.patch @@ -0,0 +1,46 @@ +From 271e0c9dce1b02a825b3cc1a7aa1fab7c381d44b Mon Sep 17 00:00:00 2001 +From: Libo Chen +Date: Fri, 20 Nov 2020 18:12:43 -0800 +Subject: ktest.pl: Fix incorrect reboot for grub2bls + +From: Libo Chen + +commit 271e0c9dce1b02a825b3cc1a7aa1fab7c381d44b upstream. + +This issue was first noticed when I was testing different kernels on +Oracle Linux 8 which as Fedora 30+ adopts BLS as default. Even though a +kernel entry was added successfully and the index of that kernel entry was +retrieved correctly, ktest still wouldn't reboot the system into +user-specified kernel. + +The bug was spotted in subroutine reboot_to where the if-statement never +checks for REBOOT_TYPE "grub2bls", therefore the desired entry will not be +set for the next boot. + +Add a check for "grub2bls" so that $grub_reboot $grub_number can +be run before a reboot if REBOOT_TYPE is "grub2bls" then we can boot to +the correct kernel. + +Link: https://lkml.kernel.org/r/20201121021243.1532477-1-libo.chen@oracle.com + +Cc: stable@vger.kernel.org +Fixes: ac2466456eaa ("ktest: introduce grub2bls REBOOT_TYPE option") +Signed-off-by: Libo Chen +Signed-off-by: Steven Rostedt (VMware) +Signed-off-by: Greg Kroah-Hartman + +--- + tools/testing/ktest/ktest.pl | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/tools/testing/ktest/ktest.pl ++++ b/tools/testing/ktest/ktest.pl +@@ -2008,7 +2008,7 @@ sub reboot_to { + + if ($reboot_type eq "grub") { + run_ssh "'(echo \"savedefault --default=$grub_number --once\" | grub --batch)'"; +- } elsif ($reboot_type eq "grub2") { ++ } elsif (($reboot_type eq "grub2") or ($reboot_type eq "grub2bls")) { + run_ssh "$grub_reboot $grub_number"; + } elsif ($reboot_type eq "syslinux") { + run_ssh "$syslinux --once \\\"$syslinux_label\\\" $syslinux_path"; diff --git a/queue-5.4/mmc-block-fixup-condition-for-cmd13-polling-for-rpmb-requests.patch b/queue-5.4/mmc-block-fixup-condition-for-cmd13-polling-for-rpmb-requests.patch new file mode 100644 index 00000000000..0caad3d0271 --- /dev/null +++ b/queue-5.4/mmc-block-fixup-condition-for-cmd13-polling-for-rpmb-requests.patch @@ -0,0 +1,40 @@ +From 6246d7c9d15aaff0bc3863f67900c6a6e6be921b Mon Sep 17 00:00:00 2001 +From: Bean Huo +Date: Wed, 2 Dec 2020 21:23:20 +0100 +Subject: mmc: block: Fixup condition for CMD13 polling for RPMB requests + +From: Bean Huo + +commit 6246d7c9d15aaff0bc3863f67900c6a6e6be921b upstream. + +The CMD13 polling is needed for commands with R1B responses. In commit +a0d4c7eb71dd ("mmc: block: Add CMD13 polling for MMC IOCTLS with R1B +response"), the intent was to introduce this for requests targeted to the +RPMB partition. However, the condition to trigger the polling loop became +wrong, leading to unnecessary polling. Let's fix the condition to avoid +this. + +Fixes: a0d4c7eb71dd ("mmc: block: Add CMD13 polling for MMC IOCTLS with R1B response") +Cc: stable@vger.kernel.org +Reported-by: Zhan Liu +Signed-off-by: Zhan Liu +Signed-off-by: Bean Huo +Link: https://lore.kernel.org/r/20201202202320.22165-1-huobean@gmail.com +Signed-off-by: Ulf Hansson +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/mmc/core/block.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/mmc/core/block.c ++++ b/drivers/mmc/core/block.c +@@ -630,7 +630,7 @@ static int __mmc_blk_ioctl_cmd(struct mm + + memcpy(&(idata->ic.response), cmd.resp, sizeof(cmd.resp)); + +- if (idata->rpmb || (cmd.flags & MMC_RSP_R1B)) { ++ if (idata->rpmb || (cmd.flags & MMC_RSP_R1B) == MMC_RSP_R1B) { + /* + * Ensure RPMB/R1B command has completed by polling CMD13 + * "Send Status". diff --git a/queue-5.4/pinctrl-amd-remove-debounce-filter-setting-in-irq-type-setting.patch b/queue-5.4/pinctrl-amd-remove-debounce-filter-setting-in-irq-type-setting.patch new file mode 100644 index 00000000000..d0a2dfb9a86 --- /dev/null +++ b/queue-5.4/pinctrl-amd-remove-debounce-filter-setting-in-irq-type-setting.patch @@ -0,0 +1,93 @@ +From 47a0001436352c9853d72bf2071e85b316d688a2 Mon Sep 17 00:00:00 2001 +From: Coiby Xu +Date: Wed, 25 Nov 2020 21:03:19 +0800 +Subject: pinctrl: amd: remove debounce filter setting in IRQ type setting + +From: Coiby Xu + +commit 47a0001436352c9853d72bf2071e85b316d688a2 upstream. + +Debounce filter setting should be independent from IRQ type setting +because according to the ACPI specs, there are separate arguments for +specifying debounce timeout and IRQ type in GpioIo() and GpioInt(). + +Together with commit 06abe8291bc31839950f7d0362d9979edc88a666 +("pinctrl: amd: fix incorrect way to disable debounce filter") and +Andy's patch "gpiolib: acpi: Take into account debounce settings" [1], +this will fix broken touchpads for laptops whose BIOS set the +debounce timeout to a relatively large value. For example, the BIOS +of Lenovo AMD gaming laptops including Legion-5 15ARH05 (R7000), +Legion-5P (R7000P) and IdeaPad Gaming 3 15ARH05, set the debounce +timeout to 124.8ms. This led to the kernel receiving only ~7 HID +reports per second from the Synaptics touchpad +(MSFT0001:00 06CB:7F28). + +Existing touchpads like [2][3] are not troubled by this bug because +the debounce timeout has been set to 0 by the BIOS before enabling +the debounce filter in setting IRQ type. + +[1] https://lore.kernel.org/linux-gpio/20201111222008.39993-11-andriy.shevchenko@linux.intel.com/ + 8dcb7a15a585 ("gpiolib: acpi: Take into account debounce settings") +[2] https://github.com/Syniurge/i2c-amd-mp2/issues/11#issuecomment-721331582 +[3] https://forum.manjaro.org/t/random-short-touchpad-freezes/30832/28 + +Signed-off-by: Coiby Xu +Reviewed-by: Andy Shevchenko +Cc: Hans de Goede +Cc: Andy Shevchenko +Cc: Benjamin Tissoires +Cc: stable@vger.kernel.org +Link: https://lore.kernel.org/linux-gpio/CAHp75VcwiGREBUJ0A06EEw-SyabqYsp%2Bdqs2DpSrhaY-2GVdAA%40mail.gmail.com/ +BugLink: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1887190 +Link: https://lore.kernel.org/r/20201125130320.311059-1-coiby.xu@gmail.com +Signed-off-by: Linus Walleij +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/pinctrl/pinctrl-amd.c | 7 ------- + 1 file changed, 7 deletions(-) + +--- a/drivers/pinctrl/pinctrl-amd.c ++++ b/drivers/pinctrl/pinctrl-amd.c +@@ -435,7 +435,6 @@ static int amd_gpio_irq_set_type(struct + pin_reg &= ~BIT(LEVEL_TRIG_OFF); + pin_reg &= ~(ACTIVE_LEVEL_MASK << ACTIVE_LEVEL_OFF); + pin_reg |= ACTIVE_HIGH << ACTIVE_LEVEL_OFF; +- pin_reg |= DB_TYPE_REMOVE_GLITCH << DB_CNTRL_OFF; + irq_set_handler_locked(d, handle_edge_irq); + break; + +@@ -443,7 +442,6 @@ static int amd_gpio_irq_set_type(struct + pin_reg &= ~BIT(LEVEL_TRIG_OFF); + pin_reg &= ~(ACTIVE_LEVEL_MASK << ACTIVE_LEVEL_OFF); + pin_reg |= ACTIVE_LOW << ACTIVE_LEVEL_OFF; +- pin_reg |= DB_TYPE_REMOVE_GLITCH << DB_CNTRL_OFF; + irq_set_handler_locked(d, handle_edge_irq); + break; + +@@ -451,7 +449,6 @@ static int amd_gpio_irq_set_type(struct + pin_reg &= ~BIT(LEVEL_TRIG_OFF); + pin_reg &= ~(ACTIVE_LEVEL_MASK << ACTIVE_LEVEL_OFF); + pin_reg |= BOTH_EADGE << ACTIVE_LEVEL_OFF; +- pin_reg |= DB_TYPE_REMOVE_GLITCH << DB_CNTRL_OFF; + irq_set_handler_locked(d, handle_edge_irq); + break; + +@@ -459,8 +456,6 @@ static int amd_gpio_irq_set_type(struct + pin_reg |= LEVEL_TRIGGER << LEVEL_TRIG_OFF; + pin_reg &= ~(ACTIVE_LEVEL_MASK << ACTIVE_LEVEL_OFF); + pin_reg |= ACTIVE_HIGH << ACTIVE_LEVEL_OFF; +- pin_reg &= ~(DB_CNTRl_MASK << DB_CNTRL_OFF); +- pin_reg |= DB_TYPE_PRESERVE_LOW_GLITCH << DB_CNTRL_OFF; + irq_set_handler_locked(d, handle_level_irq); + break; + +@@ -468,8 +463,6 @@ static int amd_gpio_irq_set_type(struct + pin_reg |= LEVEL_TRIGGER << LEVEL_TRIG_OFF; + pin_reg &= ~(ACTIVE_LEVEL_MASK << ACTIVE_LEVEL_OFF); + pin_reg |= ACTIVE_LOW << ACTIVE_LEVEL_OFF; +- pin_reg &= ~(DB_CNTRl_MASK << DB_CNTRL_OFF); +- pin_reg |= DB_TYPE_PRESERVE_HIGH_GLITCH << DB_CNTRL_OFF; + irq_set_handler_locked(d, handle_level_irq); + break; + diff --git a/queue-5.4/proc-use-untagged_addr-for-pagemap_read-addresses.patch b/queue-5.4/proc-use-untagged_addr-for-pagemap_read-addresses.patch new file mode 100644 index 00000000000..2f6804baa83 --- /dev/null +++ b/queue-5.4/proc-use-untagged_addr-for-pagemap_read-addresses.patch @@ -0,0 +1,125 @@ +From 40d6366e9d86d9a67b5642040e76082fdb5bdcf9 Mon Sep 17 00:00:00 2001 +From: Miles Chen +Date: Fri, 11 Dec 2020 13:36:31 -0800 +Subject: proc: use untagged_addr() for pagemap_read addresses + +From: Miles Chen + +commit 40d6366e9d86d9a67b5642040e76082fdb5bdcf9 upstream. + +When we try to visit the pagemap of a tagged userspace pointer, we find +that the start_vaddr is not correct because of the tag. +To fix it, we should untag the userspace pointers in pagemap_read(). + +I tested with 5.10-rc4 and the issue remains. + +Explanation from Catalin in [1]: + + "Arguably, that's a user-space bug since tagged file offsets were never + supported. In this case it's not even a tag at bit 56 as per the arm64 + tagged address ABI but rather down to bit 47. You could say that the + problem is caused by the C library (malloc()) or whoever created the + tagged vaddr and passed it to this function. It's not a kernel + regression as we've never supported it. + + Now, pagemap is a special case where the offset is usually not + generated as a classic file offset but rather derived by shifting a + user virtual address. I guess we can make a concession for pagemap + (only) and allow such offset with the tag at bit (56 - PAGE_SHIFT + 3)" + +My test code is based on [2]: + +A userspace pointer which has been tagged by 0xb4: 0xb400007662f541c8 + +userspace program: + + uint64 OsLayer::VirtualToPhysical(void *vaddr) { + uint64 frame, paddr, pfnmask, pagemask; + int pagesize = sysconf(_SC_PAGESIZE); + off64_t off = ((uintptr_t)vaddr) / pagesize * 8; // off = 0xb400007662f541c8 / pagesize * 8 = 0x5a00003b317aa0 + int fd = open(kPagemapPath, O_RDONLY); + ... + + if (lseek64(fd, off, SEEK_SET) != off || read(fd, &frame, 8) != 8) { + int err = errno; + string errtxt = ErrorString(err); + if (fd >= 0) + close(fd); + return 0; + } + ... + } + +kernel fs/proc/task_mmu.c: + + static ssize_t pagemap_read(struct file *file, char __user *buf, + size_t count, loff_t *ppos) + { + ... + src = *ppos; + svpfn = src / PM_ENTRY_BYTES; // svpfn == 0xb400007662f54 + start_vaddr = svpfn << PAGE_SHIFT; // start_vaddr == 0xb400007662f54000 + end_vaddr = mm->task_size; + + /* watch out for wraparound */ + // svpfn == 0xb400007662f54 + // (mm->task_size >> PAGE) == 0x8000000 + if (svpfn > mm->task_size >> PAGE_SHIFT) // the condition is true because of the tag 0xb4 + start_vaddr = end_vaddr; + + ret = 0; + while (count && (start_vaddr < end_vaddr)) { // we cannot visit correct entry because start_vaddr is set to end_vaddr + int len; + unsigned long end; + ... + } + ... + } + +[1] https://lore.kernel.org/patchwork/patch/1343258/ +[2] https://github.com/stressapptest/stressapptest/blob/master/src/os.cc#L158 + +Link: https://lkml.kernel.org/r/20201204024347.8295-1-miles.chen@mediatek.com +Signed-off-by: Miles Chen +Reviewed-by: Vincenzo Frascino +Reviewed-by: Catalin Marinas +Cc: Alexey Dobriyan +Cc: Andrey Konovalov +Cc: Alexander Potapenko +Cc: Vincenzo Frascino +Cc: Andrey Ryabinin +Cc: Catalin Marinas +Cc: Dmitry Vyukov +Cc: Marco Elver +Cc: Will Deacon +Cc: Eric W. Biederman +Cc: Song Bao Hua (Barry Song) +Cc: [5.4-] +Signed-off-by: Andrew Morton +Signed-off-by: Linus Torvalds +Signed-off-by: Greg Kroah-Hartman + +--- + fs/proc/task_mmu.c | 8 ++++++-- + 1 file changed, 6 insertions(+), 2 deletions(-) + +--- a/fs/proc/task_mmu.c ++++ b/fs/proc/task_mmu.c +@@ -1567,11 +1567,15 @@ static ssize_t pagemap_read(struct file + + src = *ppos; + svpfn = src / PM_ENTRY_BYTES; +- start_vaddr = svpfn << PAGE_SHIFT; + end_vaddr = mm->task_size; + + /* watch out for wraparound */ +- if (svpfn > mm->task_size >> PAGE_SHIFT) ++ start_vaddr = end_vaddr; ++ if (svpfn <= (ULONG_MAX >> PAGE_SHIFT)) ++ start_vaddr = untagged_addr(svpfn << PAGE_SHIFT); ++ ++ /* Ensure the address is inside the task */ ++ if (start_vaddr > mm->task_size) + start_vaddr = end_vaddr; + + /* diff --git a/queue-5.4/scsi-be2iscsi-revert-fix-a-theoretical-leak-in-beiscsi_create_eqs.patch b/queue-5.4/scsi-be2iscsi-revert-fix-a-theoretical-leak-in-beiscsi_create_eqs.patch new file mode 100644 index 00000000000..06748536ad7 --- /dev/null +++ b/queue-5.4/scsi-be2iscsi-revert-fix-a-theoretical-leak-in-beiscsi_create_eqs.patch @@ -0,0 +1,61 @@ +From eeaf06af6f87e1dba371fbe42674e6f963220b9c Mon Sep 17 00:00:00 2001 +From: Dan Carpenter +Date: Thu, 3 Dec 2020 15:18:26 +0300 +Subject: scsi: be2iscsi: Revert "Fix a theoretical leak in beiscsi_create_eqs()" + +From: Dan Carpenter + +commit eeaf06af6f87e1dba371fbe42674e6f963220b9c upstream. + +My patch caused kernel Oopses and delays in boot. Revert it. + +The problem was that I moved the "mem->dma = paddr;" before the call to +be_fill_queue(). But the first thing that the be_fill_queue() function +does is memset the whole struct to zero which overwrites the assignment. + +Link: https://lore.kernel.org/r/X8jXkt6eThjyVP1v@mwanda +Fixes: 38b2db564d9a ("scsi: be2iscsi: Fix a theoretical leak in beiscsi_create_eqs()") +Cc: stable +Reported-by: Thomas Lamprecht +Signed-off-by: Dan Carpenter +Signed-off-by: Martin K. Petersen +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/scsi/be2iscsi/be_main.c | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +--- a/drivers/scsi/be2iscsi/be_main.c ++++ b/drivers/scsi/be2iscsi/be_main.c +@@ -3020,7 +3020,6 @@ static int beiscsi_create_eqs(struct bei + goto create_eq_error; + } + +- mem->dma = paddr; + mem->va = eq_vaddress; + ret = be_fill_queue(eq, phba->params.num_eq_entries, + sizeof(struct be_eq_entry), eq_vaddress); +@@ -3030,6 +3029,7 @@ static int beiscsi_create_eqs(struct bei + goto create_eq_error; + } + ++ mem->dma = paddr; + ret = beiscsi_cmd_eq_create(&phba->ctrl, eq, + BEISCSI_EQ_DELAY_DEF); + if (ret) { +@@ -3086,7 +3086,6 @@ static int beiscsi_create_cqs(struct bei + goto create_cq_error; + } + +- mem->dma = paddr; + ret = be_fill_queue(cq, phba->params.num_cq_entries, + sizeof(struct sol_cqe), cq_vaddress); + if (ret) { +@@ -3096,6 +3095,7 @@ static int beiscsi_create_cqs(struct bei + goto create_cq_error; + } + ++ mem->dma = paddr; + ret = beiscsi_cmd_cq_create(&phba->ctrl, cq, eq, false, + false, 0); + if (ret) { diff --git a/queue-5.4/series b/queue-5.4/series index fb2e64ccf01..c14f6dd1cfb 100644 --- a/queue-5.4/series +++ b/queue-5.4/series @@ -20,3 +20,15 @@ platform-x86-acer-wmi-add-automatic-keyboard-backgro.patch platform-x86-intel-vbtn-support-for-tablet-mode-on-h.patch platform-x86-touchscreen_dmi-add-info-for-the-irbis-.patch can-m_can-m_can_dev_setup-add-support-for-bosch-mcan.patch +ktest.pl-fix-incorrect-reboot-for-grub2bls.patch +input-cm109-do-not-stomp-on-control-urb.patch +input-i8042-add-acer-laptops-to-the-i8042-reset-list.patch +pinctrl-amd-remove-debounce-filter-setting-in-irq-type-setting.patch +mmc-block-fixup-condition-for-cmd13-polling-for-rpmb-requests.patch +drm-i915-display-dp-compute-the-correct-slice-count-for-vdsc-on-dp.patch +kbuild-avoid-static_assert-for-genksyms.patch +proc-use-untagged_addr-for-pagemap_read-addresses.patch +scsi-be2iscsi-revert-fix-a-theoretical-leak-in-beiscsi_create_eqs.patch +x86-mm-mem_encrypt-fix-definition-of-pmd_flags_dec_wp.patch +x86-membarrier-get-rid-of-a-dubious-optimization.patch +x86-apic-vector-fix-ordering-in-vector-assignment.patch diff --git a/queue-5.4/x86-apic-vector-fix-ordering-in-vector-assignment.patch b/queue-5.4/x86-apic-vector-fix-ordering-in-vector-assignment.patch new file mode 100644 index 00000000000..b431d218a92 --- /dev/null +++ b/queue-5.4/x86-apic-vector-fix-ordering-in-vector-assignment.patch @@ -0,0 +1,90 @@ +From 190113b4c6531c8e09b31d5235f9b5175cbb0f72 Mon Sep 17 00:00:00 2001 +From: Thomas Gleixner +Date: Thu, 10 Dec 2020 21:18:22 +0100 +Subject: x86/apic/vector: Fix ordering in vector assignment + +From: Thomas Gleixner + +commit 190113b4c6531c8e09b31d5235f9b5175cbb0f72 upstream. + +Prarit reported that depending on the affinity setting the + + ' irq $N: Affinity broken due to vector space exhaustion.' + +message is showing up in dmesg, but the vector space on the CPUs in the +affinity mask is definitely not exhausted. + +Shung-Hsi provided traces and analysis which pinpoints the problem: + +The ordering of trying to assign an interrupt vector in +assign_irq_vector_any_locked() is simply wrong if the interrupt data has a +valid node assigned. It does: + + 1) Try the intersection of affinity mask and node mask + 2) Try the node mask + 3) Try the full affinity mask + 4) Try the full online mask + +Obviously #2 and #3 are in the wrong order as the requested affinity +mask has to take precedence. + +In the observed cases #1 failed because the affinity mask did not contain +CPUs from node 0. That made it allocate a vector from node 0, thereby +breaking affinity and emitting the misleading message. + +Revert the order of #2 and #3 so the full affinity mask without the node +intersection is tried before actually affinity is broken. + +If no node is assigned then only the full affinity mask and if that fails +the full online mask is tried. + +Fixes: d6ffc6ac83b1 ("x86/vector: Respect affinity mask in irq descriptor") +Reported-by: Prarit Bhargava +Reported-by: Shung-Hsi Yu +Signed-off-by: Thomas Gleixner +Tested-by: Shung-Hsi Yu +Cc: stable@vger.kernel.org +Link: https://lore.kernel.org/r/87ft4djtyp.fsf@nanos.tec.linutronix.de +Signed-off-by: Greg Kroah-Hartman + +--- + arch/x86/kernel/apic/vector.c | 24 ++++++++++++++---------- + 1 file changed, 14 insertions(+), 10 deletions(-) + +--- a/arch/x86/kernel/apic/vector.c ++++ b/arch/x86/kernel/apic/vector.c +@@ -272,20 +272,24 @@ static int assign_irq_vector_any_locked( + const struct cpumask *affmsk = irq_data_get_affinity_mask(irqd); + int node = irq_data_get_node(irqd); + +- if (node == NUMA_NO_NODE) +- goto all; +- /* Try the intersection of @affmsk and node mask */ +- cpumask_and(vector_searchmask, cpumask_of_node(node), affmsk); +- if (!assign_vector_locked(irqd, vector_searchmask)) +- return 0; +- /* Try the node mask */ +- if (!assign_vector_locked(irqd, cpumask_of_node(node))) +- return 0; +-all: ++ if (node != NUMA_NO_NODE) { ++ /* Try the intersection of @affmsk and node mask */ ++ cpumask_and(vector_searchmask, cpumask_of_node(node), affmsk); ++ if (!assign_vector_locked(irqd, vector_searchmask)) ++ return 0; ++ } ++ + /* Try the full affinity mask */ + cpumask_and(vector_searchmask, affmsk, cpu_online_mask); + if (!assign_vector_locked(irqd, vector_searchmask)) + return 0; ++ ++ if (node != NUMA_NO_NODE) { ++ /* Try the node mask */ ++ if (!assign_vector_locked(irqd, cpumask_of_node(node))) ++ return 0; ++ } ++ + /* Try the full online mask */ + return assign_vector_locked(irqd, cpu_online_mask); + } diff --git a/queue-5.4/x86-membarrier-get-rid-of-a-dubious-optimization.patch b/queue-5.4/x86-membarrier-get-rid-of-a-dubious-optimization.patch new file mode 100644 index 00000000000..2d4feb25eb4 --- /dev/null +++ b/queue-5.4/x86-membarrier-get-rid-of-a-dubious-optimization.patch @@ -0,0 +1,70 @@ +From a493d1ca1a03b532871f1da27f8dbda2b28b04c4 Mon Sep 17 00:00:00 2001 +From: Andy Lutomirski +Date: Thu, 3 Dec 2020 21:07:03 -0800 +Subject: x86/membarrier: Get rid of a dubious optimization + +From: Andy Lutomirski + +commit a493d1ca1a03b532871f1da27f8dbda2b28b04c4 upstream. + +sync_core_before_usermode() had an incorrect optimization. If the kernel +returns from an interrupt, it can get to usermode without IRET. It just has +to schedule to a different task in the same mm and do SYSRET. Fortunately, +there were no callers of sync_core_before_usermode() that could have had +in_irq() or in_nmi() equal to true, because it's only ever called from the +scheduler. + +While at it, clarify a related comment. + +Fixes: 70216e18e519 ("membarrier: Provide core serializing command, *_SYNC_CORE") +Signed-off-by: Andy Lutomirski +Signed-off-by: Thomas Gleixner +Reviewed-by: Mathieu Desnoyers +Cc: stable@vger.kernel.org +Link: https://lore.kernel.org/r/5afc7632be1422f91eaf7611aaaa1b5b8580a086.1607058304.git.luto@kernel.org +Signed-off-by: Greg Kroah-Hartman + +--- + arch/x86/include/asm/sync_core.h | 9 +++++---- + arch/x86/mm/tlb.c | 10 ++++++++-- + 2 files changed, 13 insertions(+), 6 deletions(-) + +--- a/arch/x86/include/asm/sync_core.h ++++ b/arch/x86/include/asm/sync_core.h +@@ -16,12 +16,13 @@ static inline void sync_core_before_user + /* With PTI, we unconditionally serialize before running user code. */ + if (static_cpu_has(X86_FEATURE_PTI)) + return; ++ + /* +- * Return from interrupt and NMI is done through iret, which is core +- * serializing. ++ * Even if we're in an interrupt, we might reschedule before returning, ++ * in which case we could switch to a different thread in the same mm ++ * and return using SYSRET or SYSEXIT. Instead of trying to keep ++ * track of our need to sync the core, just sync right away. + */ +- if (in_irq() || in_nmi()) +- return; + sync_core(); + } + +--- a/arch/x86/mm/tlb.c ++++ b/arch/x86/mm/tlb.c +@@ -327,8 +327,14 @@ void switch_mm_irqs_off(struct mm_struct + /* + * The membarrier system call requires a full memory barrier and + * core serialization before returning to user-space, after +- * storing to rq->curr. Writing to CR3 provides that full +- * memory barrier and core serializing instruction. ++ * storing to rq->curr, when changing mm. This is because ++ * membarrier() sends IPIs to all CPUs that are in the target mm ++ * to make them issue memory barriers. However, if another CPU ++ * switches to/from the target mm concurrently with ++ * membarrier(), it can cause that CPU not to receive an IPI ++ * when it really should issue a memory barrier. Writing to CR3 ++ * provides that full memory barrier and core serializing ++ * instruction. + */ + if (real_prev == next) { + VM_WARN_ON(this_cpu_read(cpu_tlbstate.ctxs[prev_asid].ctx_id) != diff --git a/queue-5.4/x86-mm-mem_encrypt-fix-definition-of-pmd_flags_dec_wp.patch b/queue-5.4/x86-mm-mem_encrypt-fix-definition-of-pmd_flags_dec_wp.patch new file mode 100644 index 00000000000..5b43bc2bfde --- /dev/null +++ b/queue-5.4/x86-mm-mem_encrypt-fix-definition-of-pmd_flags_dec_wp.patch @@ -0,0 +1,53 @@ +From 29ac40cbed2bc06fa218ca25d7f5e280d3d08a25 Mon Sep 17 00:00:00 2001 +From: Arvind Sankar +Date: Wed, 11 Nov 2020 11:09:45 -0500 +Subject: x86/mm/mem_encrypt: Fix definition of PMD_FLAGS_DEC_WP + +From: Arvind Sankar + +commit 29ac40cbed2bc06fa218ca25d7f5e280d3d08a25 upstream. + +The PAT bit is in different locations for 4k and 2M/1G page table +entries. + +Add a definition for _PAGE_LARGE_CACHE_MASK to represent the three +caching bits (PWT, PCD, PAT), similar to _PAGE_CACHE_MASK for 4k pages, +and use it in the definition of PMD_FLAGS_DEC_WP to get the correct PAT +index for write-protected pages. + +Fixes: 6ebcb060713f ("x86/mm: Add support to encrypt the kernel in-place") +Signed-off-by: Arvind Sankar +Signed-off-by: Borislav Petkov +Tested-by: Tom Lendacky +Cc: stable@vger.kernel.org +Link: https://lkml.kernel.org/r/20201111160946.147341-1-nivedita@alum.mit.edu +Signed-off-by: Greg Kroah-Hartman + +--- + arch/x86/include/asm/pgtable_types.h | 1 + + arch/x86/mm/mem_encrypt_identity.c | 4 ++-- + 2 files changed, 3 insertions(+), 2 deletions(-) + +--- a/arch/x86/include/asm/pgtable_types.h ++++ b/arch/x86/include/asm/pgtable_types.h +@@ -147,6 +147,7 @@ enum page_cache_mode { + #endif + + #define _PAGE_CACHE_MASK (_PAGE_PAT | _PAGE_PCD | _PAGE_PWT) ++#define _PAGE_LARGE_CACHE_MASK (_PAGE_PWT | _PAGE_PCD | _PAGE_PAT_LARGE) + #define _PAGE_NOCACHE (cachemode2protval(_PAGE_CACHE_MODE_UC)) + #define _PAGE_CACHE_WP (cachemode2protval(_PAGE_CACHE_MODE_WP)) + +--- a/arch/x86/mm/mem_encrypt_identity.c ++++ b/arch/x86/mm/mem_encrypt_identity.c +@@ -45,8 +45,8 @@ + #define PMD_FLAGS_LARGE (__PAGE_KERNEL_LARGE_EXEC & ~_PAGE_GLOBAL) + + #define PMD_FLAGS_DEC PMD_FLAGS_LARGE +-#define PMD_FLAGS_DEC_WP ((PMD_FLAGS_DEC & ~_PAGE_CACHE_MASK) | \ +- (_PAGE_PAT | _PAGE_PWT)) ++#define PMD_FLAGS_DEC_WP ((PMD_FLAGS_DEC & ~_PAGE_LARGE_CACHE_MASK) | \ ++ (_PAGE_PAT_LARGE | _PAGE_PWT)) + + #define PMD_FLAGS_ENC (PMD_FLAGS_LARGE | _PAGE_ENC) +