From c25f86d3898cd26ce444feaa1da118908d1d4795 Mon Sep 17 00:00:00 2001 From: Greg Kroah-Hartman Date: Sun, 19 Jan 2020 16:10:33 +0100 Subject: [PATCH] 5.4-stable patches added patches: clk-samsung-exynos5420-keep-top-g3d-clocks-enabled.patch cpu-smt-fix-x86-link-error-without-config_sysfs.patch drm-i915-add-missing-include-file-linux-math64.h.patch efi-earlycon-fix-write-combine-mapping-on-x86.patch locking-lockdep-fix-buffer-overrun-problem-in-stack_trace.patch locking-rwsem-fix-kernel-crash-when-spinning-on-rwsem_owner_unknown.patch mtd-rawnand-gpmi-fix-suspend-resume-problem.patch mtd-rawnand-gpmi-restore-nfc-timing-setup-after-suspend-resume.patch mtd-spi-nor-fix-selection-of-4-byte-addressing-opcodes-on-spansion.patch perf-hists-fix-variable-name-s-inconsistency-in-hists__for_each-macro.patch perf-report-fix-incorrectly-added-dimensions-as-switch-perf-data-file.patch perf-x86-intel-uncore-fix-missing-marker-for-snr_uncore_imc_freerunning_events.patch ptrace-reintroduce-usage-of-subjective-credentials-in-ptrace_has_cap.patch s390-setup-fix-secure-ipl-message.patch s390-zcrypt-fix-cca-cipher-key-gen-with-clear-key-value-function.patch scsi-storvsc-correctly-set-number-of-hardware-queues-for-ide-disk.patch usb-core-hub-improved-device-recognition-on-remote-wakeup.patch x86-cpu-amd-ensure-clearing-of-sme-sev-features-is-maintained.patch x86-efistub-disable-paging-at-mixed-mode-entry.patch x86-resctrl-fix-an-imbalance-in-domain_remove_cpu.patch x86-resctrl-fix-potential-memory-leak.patch --- ...ynos5420-keep-top-g3d-clocks-enabled.patch | 109 ++++++++++ ...-x86-link-error-without-config_sysfs.patch | 195 ++++++++++++++++++ ...-missing-include-file-linux-math64.h.patch | 39 ++++ ...con-fix-write-combine-mapping-on-x86.patch | 84 ++++++++ ...uffer-overrun-problem-in-stack_trace.patch | 66 ++++++ ...when-spinning-on-rwsem_owner_unknown.patch | 44 ++++ ...nand-gpmi-fix-suspend-resume-problem.patch | 52 +++++ ...fc-timing-setup-after-suspend-resume.patch | 37 ++++ ...-byte-addressing-opcodes-on-spansion.patch | 39 ++++ ...consistency-in-hists__for_each-macro.patch | 45 ++++ ...-dimensions-as-switch-perf-data-file.patch | 69 +++++++ ...or-snr_uncore_imc_freerunning_events.patch | 37 ++++ ...ective-credentials-in-ptrace_has_cap.patch | 100 +++++++++ .../s390-setup-fix-secure-ipl-message.patch | 34 +++ ...ey-gen-with-clear-key-value-function.patch | 38 ++++ ...mber-of-hardware-queues-for-ide-disk.patch | 44 ++++ queue-5.4/series | 21 ++ ...-device-recognition-on-remote-wakeup.patch | 65 ++++++ ...ng-of-sme-sev-features-is-maintained.patch | 41 ++++ ...b-disable-paging-at-mixed-mode-entry.patch | 46 +++++ ...ix-an-imbalance-in-domain_remove_cpu.patch | 75 +++++++ ...86-resctrl-fix-potential-memory-leak.patch | 54 +++++ 22 files changed, 1334 insertions(+) create mode 100644 queue-5.4/clk-samsung-exynos5420-keep-top-g3d-clocks-enabled.patch create mode 100644 queue-5.4/cpu-smt-fix-x86-link-error-without-config_sysfs.patch create mode 100644 queue-5.4/drm-i915-add-missing-include-file-linux-math64.h.patch create mode 100644 queue-5.4/efi-earlycon-fix-write-combine-mapping-on-x86.patch create mode 100644 queue-5.4/locking-lockdep-fix-buffer-overrun-problem-in-stack_trace.patch create mode 100644 queue-5.4/locking-rwsem-fix-kernel-crash-when-spinning-on-rwsem_owner_unknown.patch create mode 100644 queue-5.4/mtd-rawnand-gpmi-fix-suspend-resume-problem.patch create mode 100644 queue-5.4/mtd-rawnand-gpmi-restore-nfc-timing-setup-after-suspend-resume.patch create mode 100644 queue-5.4/mtd-spi-nor-fix-selection-of-4-byte-addressing-opcodes-on-spansion.patch create mode 100644 queue-5.4/perf-hists-fix-variable-name-s-inconsistency-in-hists__for_each-macro.patch create mode 100644 queue-5.4/perf-report-fix-incorrectly-added-dimensions-as-switch-perf-data-file.patch create mode 100644 queue-5.4/perf-x86-intel-uncore-fix-missing-marker-for-snr_uncore_imc_freerunning_events.patch create mode 100644 queue-5.4/ptrace-reintroduce-usage-of-subjective-credentials-in-ptrace_has_cap.patch create mode 100644 queue-5.4/s390-setup-fix-secure-ipl-message.patch create mode 100644 queue-5.4/s390-zcrypt-fix-cca-cipher-key-gen-with-clear-key-value-function.patch create mode 100644 queue-5.4/scsi-storvsc-correctly-set-number-of-hardware-queues-for-ide-disk.patch create mode 100644 queue-5.4/usb-core-hub-improved-device-recognition-on-remote-wakeup.patch create mode 100644 queue-5.4/x86-cpu-amd-ensure-clearing-of-sme-sev-features-is-maintained.patch create mode 100644 queue-5.4/x86-efistub-disable-paging-at-mixed-mode-entry.patch create mode 100644 queue-5.4/x86-resctrl-fix-an-imbalance-in-domain_remove_cpu.patch create mode 100644 queue-5.4/x86-resctrl-fix-potential-memory-leak.patch diff --git a/queue-5.4/clk-samsung-exynos5420-keep-top-g3d-clocks-enabled.patch b/queue-5.4/clk-samsung-exynos5420-keep-top-g3d-clocks-enabled.patch new file mode 100644 index 00000000000..04d03a0b609 --- /dev/null +++ b/queue-5.4/clk-samsung-exynos5420-keep-top-g3d-clocks-enabled.patch @@ -0,0 +1,109 @@ +From 67f96ff7c8f073648696eab50fd23ded23441067 Mon Sep 17 00:00:00 2001 +From: Marek Szyprowski +Date: Mon, 16 Dec 2019 14:14:07 +0100 +Subject: clk: samsung: exynos5420: Keep top G3D clocks enabled + +From: Marek Szyprowski + +commit 67f96ff7c8f073648696eab50fd23ded23441067 upstream. + +In Exynos542x/5800 SoCs, the G3D leaf clocks are located in the G3D power +domain. This is similar to the other hardware modules and their power +domains. However there is one thing specific to G3D clocks hierarchy. +Unlike other hardware modules, the G3D clocks hierarchy doesn't have any +gate clock between the TOP part of the hierarchy and the part located in +the power domain and some SoC internal busses are sourced directly from +the TOP muxes. The consequence of this design if the fact that the TOP +part of the hierarchy has to be enabled permanently to ensure proper +operation of the SoC power related components (G3D power domain and +Exynos Power Management Unit for system suspend/resume). + +This patch adds an explicit call to clk_prepare_enable() on the last MUX +in the TOP part of G3D clock hierarchy to keep it enabled permanently to +ensure that the internal busses get their clock regardless of the main +G3D clock enablement status. + +This fixes following imprecise abort issue observed on Odroid XU3/XU4 +after enabling Panfrost driver by commit 1a5a85c56402 "ARM: dts: exynos: +Add Mali/GPU node on Exynos5420 and enable it on Odroid XU3/4"): + +panfrost 11800000.gpu: clock rate = 400000000 +panfrost 11800000.gpu: failed to get regulator: -517 +panfrost 11800000.gpu: regulator init failed -517 +Power domain G3D disable failed +... +panfrost 11800000.gpu: clock rate = 400000000 +8<--- cut here --- +Unhandled fault: imprecise external abort (0x1406) at 0x00000000 +pgd = (ptrval) +[00000000] *pgd=00000000 +Internal error: : 1406 [#1] PREEMPT SMP ARM +Modules linked in: +CPU: 7 PID: 53 Comm: kworker/7:1 Not tainted 5.4.0-rc8-next-20191119-00032-g56f1001191a6 #6923 +Hardware name: SAMSUNG EXYNOS (Flattened Device Tree) +Workqueue: events deferred_probe_work_func +PC is at panfrost_gpu_soft_reset+0x94/0x110 +LR is at ___might_sleep+0x128/0x2dc +... +[] (panfrost_gpu_soft_reset) from [] (panfrost_gpu_init+0x10/0x67c) +[] (panfrost_gpu_init) from [] (panfrost_device_init+0x158/0x2cc) +[] (panfrost_device_init) from [] (panfrost_probe+0x80/0x178) +[] (panfrost_probe) from [] (platform_drv_probe+0x48/0x9c) +[] (platform_drv_probe) from [] (really_probe+0x1c4/0x474) +[] (really_probe) from [] (driver_probe_device+0x78/0x1bc) +[] (driver_probe_device) from [] (bus_for_each_drv+0x74/0xb8) +[] (bus_for_each_drv) from [] (__device_attach+0xd4/0x16c) +[] (__device_attach) from [] (bus_probe_device+0x88/0x90) +[] (bus_probe_device) from [] (deferred_probe_work_func+0x4c/0xd0) +[] (deferred_probe_work_func) from [] (process_one_work+0x300/0x864) +[] (process_one_work) from [] (worker_thread+0x58/0x5a0) +[] (worker_thread) from [] (kthread+0x12c/0x160) +[] (kthread) from [] (ret_from_fork+0x14/0x20) +Exception stack(0xee03dfb0 to 0xee03dff8) +... +Code: e594300c e5933020 e3130c01 1a00000f (ebefff50). +---[ end trace badde2b74a65a540 ]--- + +In the above case, the Panfrost driver disables G3D clocks after failure +of getting the needed regulator and return with -EPROVE_DEFER code. This +causes G3D power domain disable failure and then, during second probe +an imprecise abort is triggered due to undefined power domain state. + +Fixes: 45f10dabb56b ("clk: samsung: exynos5420: Add SET_RATE_PARENT flag to clocks on G3D path") +Fixes: c9f7567aff31 ("clk: samsung: exynos542x: Move G3D subsystem clocks to its sub-CMU") +Signed-off-by: Marek Szyprowski +Link: https://lkml.kernel.org/r/20191216131407.17225-1-m.szyprowski@samsung.com +Acked-by: Krzysztof Kozlowski +Acked-by: Chanwoo Choi +Acked-by: Sylwester Nawrocki +Signed-off-by: Stephen Boyd +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/clk/samsung/clk-exynos5420.c | 8 ++++++++ + 1 file changed, 8 insertions(+) + +--- a/drivers/clk/samsung/clk-exynos5420.c ++++ b/drivers/clk/samsung/clk-exynos5420.c +@@ -12,6 +12,7 @@ + #include + #include + #include ++#include + + #include "clk.h" + #include "clk-cpu.h" +@@ -1630,6 +1631,13 @@ static void __init exynos5x_clk_init(str + exynos5x_subcmus); + } + ++ /* ++ * Keep top part of G3D clock path enabled permanently to ensure ++ * that the internal busses get their clock regardless of the ++ * main G3D clock enablement status. ++ */ ++ clk_prepare_enable(__clk_lookup("mout_sw_aclk_g3d")); ++ + samsung_clk_of_add_provider(np, ctx); + } + diff --git a/queue-5.4/cpu-smt-fix-x86-link-error-without-config_sysfs.patch b/queue-5.4/cpu-smt-fix-x86-link-error-without-config_sysfs.patch new file mode 100644 index 00000000000..e7b2ae480d6 --- /dev/null +++ b/queue-5.4/cpu-smt-fix-x86-link-error-without-config_sysfs.patch @@ -0,0 +1,195 @@ +From dc8d37ed304eeeea47e65fb9edc1c6c8b0093386 Mon Sep 17 00:00:00 2001 +From: Arnd Bergmann +Date: Tue, 10 Dec 2019 20:56:04 +0100 +Subject: cpu/SMT: Fix x86 link error without CONFIG_SYSFS + +From: Arnd Bergmann + +commit dc8d37ed304eeeea47e65fb9edc1c6c8b0093386 upstream. + +When CONFIG_SYSFS is disabled, but CONFIG_HOTPLUG_SMT is enabled, +the kernel fails to link: + +arch/x86/power/cpu.o: In function `hibernate_resume_nonboot_cpu_disable': +(.text+0x38d): undefined reference to `cpuhp_smt_enable' +arch/x86/power/hibernate.o: In function `arch_resume_nosmt': +hibernate.c:(.text+0x291): undefined reference to `cpuhp_smt_enable' +hibernate.c:(.text+0x29c): undefined reference to `cpuhp_smt_disable' + +Move the exported functions out of the #ifdef section into its +own with the correct conditions. + +The patch that caused this is marked for stable backports, so +this one may need to be backported as well. + +Fixes: ec527c318036 ("x86/power: Fix 'nosmt' vs hibernation triple fault during resume") +Signed-off-by: Arnd Bergmann +Signed-off-by: Thomas Gleixner +Reviewed-by: Jiri Kosina +Cc: stable@vger.kernel.org +Link: https://lore.kernel.org/r/20191210195614.786555-1-arnd@arndb.de +Signed-off-by: Greg Kroah-Hartman + +--- + kernel/cpu.c | 143 +++++++++++++++++++++++++++++------------------------------ + 1 file changed, 72 insertions(+), 71 deletions(-) + +--- a/kernel/cpu.c ++++ b/kernel/cpu.c +@@ -1909,6 +1909,78 @@ void __cpuhp_remove_state(enum cpuhp_sta + } + EXPORT_SYMBOL(__cpuhp_remove_state); + ++#ifdef CONFIG_HOTPLUG_SMT ++static void cpuhp_offline_cpu_device(unsigned int cpu) ++{ ++ struct device *dev = get_cpu_device(cpu); ++ ++ dev->offline = true; ++ /* Tell user space about the state change */ ++ kobject_uevent(&dev->kobj, KOBJ_OFFLINE); ++} ++ ++static void cpuhp_online_cpu_device(unsigned int cpu) ++{ ++ struct device *dev = get_cpu_device(cpu); ++ ++ dev->offline = false; ++ /* Tell user space about the state change */ ++ kobject_uevent(&dev->kobj, KOBJ_ONLINE); ++} ++ ++int cpuhp_smt_disable(enum cpuhp_smt_control ctrlval) ++{ ++ int cpu, ret = 0; ++ ++ cpu_maps_update_begin(); ++ for_each_online_cpu(cpu) { ++ if (topology_is_primary_thread(cpu)) ++ continue; ++ ret = cpu_down_maps_locked(cpu, CPUHP_OFFLINE); ++ if (ret) ++ break; ++ /* ++ * As this needs to hold the cpu maps lock it's impossible ++ * to call device_offline() because that ends up calling ++ * cpu_down() which takes cpu maps lock. cpu maps lock ++ * needs to be held as this might race against in kernel ++ * abusers of the hotplug machinery (thermal management). ++ * ++ * So nothing would update device:offline state. That would ++ * leave the sysfs entry stale and prevent onlining after ++ * smt control has been changed to 'off' again. This is ++ * called under the sysfs hotplug lock, so it is properly ++ * serialized against the regular offline usage. ++ */ ++ cpuhp_offline_cpu_device(cpu); ++ } ++ if (!ret) ++ cpu_smt_control = ctrlval; ++ cpu_maps_update_done(); ++ return ret; ++} ++ ++int cpuhp_smt_enable(void) ++{ ++ int cpu, ret = 0; ++ ++ cpu_maps_update_begin(); ++ cpu_smt_control = CPU_SMT_ENABLED; ++ for_each_present_cpu(cpu) { ++ /* Skip online CPUs and CPUs on offline nodes */ ++ if (cpu_online(cpu) || !node_online(cpu_to_node(cpu))) ++ continue; ++ ret = _cpu_up(cpu, 0, CPUHP_ONLINE); ++ if (ret) ++ break; ++ /* See comment in cpuhp_smt_disable() */ ++ cpuhp_online_cpu_device(cpu); ++ } ++ cpu_maps_update_done(); ++ return ret; ++} ++#endif ++ + #if defined(CONFIG_SYSFS) && defined(CONFIG_HOTPLUG_CPU) + static ssize_t show_cpuhp_state(struct device *dev, + struct device_attribute *attr, char *buf) +@@ -2063,77 +2135,6 @@ static const struct attribute_group cpuh + + #ifdef CONFIG_HOTPLUG_SMT + +-static void cpuhp_offline_cpu_device(unsigned int cpu) +-{ +- struct device *dev = get_cpu_device(cpu); +- +- dev->offline = true; +- /* Tell user space about the state change */ +- kobject_uevent(&dev->kobj, KOBJ_OFFLINE); +-} +- +-static void cpuhp_online_cpu_device(unsigned int cpu) +-{ +- struct device *dev = get_cpu_device(cpu); +- +- dev->offline = false; +- /* Tell user space about the state change */ +- kobject_uevent(&dev->kobj, KOBJ_ONLINE); +-} +- +-int cpuhp_smt_disable(enum cpuhp_smt_control ctrlval) +-{ +- int cpu, ret = 0; +- +- cpu_maps_update_begin(); +- for_each_online_cpu(cpu) { +- if (topology_is_primary_thread(cpu)) +- continue; +- ret = cpu_down_maps_locked(cpu, CPUHP_OFFLINE); +- if (ret) +- break; +- /* +- * As this needs to hold the cpu maps lock it's impossible +- * to call device_offline() because that ends up calling +- * cpu_down() which takes cpu maps lock. cpu maps lock +- * needs to be held as this might race against in kernel +- * abusers of the hotplug machinery (thermal management). +- * +- * So nothing would update device:offline state. That would +- * leave the sysfs entry stale and prevent onlining after +- * smt control has been changed to 'off' again. This is +- * called under the sysfs hotplug lock, so it is properly +- * serialized against the regular offline usage. +- */ +- cpuhp_offline_cpu_device(cpu); +- } +- if (!ret) +- cpu_smt_control = ctrlval; +- cpu_maps_update_done(); +- return ret; +-} +- +-int cpuhp_smt_enable(void) +-{ +- int cpu, ret = 0; +- +- cpu_maps_update_begin(); +- cpu_smt_control = CPU_SMT_ENABLED; +- for_each_present_cpu(cpu) { +- /* Skip online CPUs and CPUs on offline nodes */ +- if (cpu_online(cpu) || !node_online(cpu_to_node(cpu))) +- continue; +- ret = _cpu_up(cpu, 0, CPUHP_ONLINE); +- if (ret) +- break; +- /* See comment in cpuhp_smt_disable() */ +- cpuhp_online_cpu_device(cpu); +- } +- cpu_maps_update_done(); +- return ret; +-} +- +- + static ssize_t + __store_smt_control(struct device *dev, struct device_attribute *attr, + const char *buf, size_t count) diff --git a/queue-5.4/drm-i915-add-missing-include-file-linux-math64.h.patch b/queue-5.4/drm-i915-add-missing-include-file-linux-math64.h.patch new file mode 100644 index 00000000000..3aae3d0710e --- /dev/null +++ b/queue-5.4/drm-i915-add-missing-include-file-linux-math64.h.patch @@ -0,0 +1,39 @@ +From ea38aa2ea5b0969776f0a47f174ce928a22be803 Mon Sep 17 00:00:00 2001 +From: YueHaibing +Date: Tue, 7 Jan 2020 21:50:14 +0800 +Subject: drm/i915: Add missing include file + +From: YueHaibing + +commit ea38aa2ea5b0969776f0a47f174ce928a22be803 upstream. + +Fix build error: +./drivers/gpu/drm/i915/selftests/i915_random.h: In function i915_prandom_u32_max_state: +./drivers/gpu/drm/i915/selftests/i915_random.h:48:23: error: + implicit declaration of function mul_u32_u32; did you mean mul_u64_u32_div? [-Werror=implicit-function-declaration] + return upper_32_bits(mul_u32_u32(prandom_u32_state(state), ep_ro)); + +Reported-by: Hulk Robot +Fixes: 7ce5b6850b47 ("drm/i915/selftests: Use mul_u32_u32() for 32b x 32b -> 64b result") +Signed-off-by: YueHaibing +Reviewed-by: Chris Wilson +Signed-off-by: Chris Wilson +Link: https://patchwork.freedesktop.org/patch/msgid/20200107135014.36472-1-yuehaibing@huawei.com +(cherry picked from commit 62bf5465b26d1f502430b9c654be7d16bf2e242d) +Signed-off-by: Joonas Lahtinen +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/gpu/drm/i915/selftests/i915_random.h | 1 + + 1 file changed, 1 insertion(+) + +--- a/drivers/gpu/drm/i915/selftests/i915_random.h ++++ b/drivers/gpu/drm/i915/selftests/i915_random.h +@@ -25,6 +25,7 @@ + #ifndef __I915_SELFTESTS_RANDOM_H__ + #define __I915_SELFTESTS_RANDOM_H__ + ++#include + #include + + #include "../i915_selftest.h" diff --git a/queue-5.4/efi-earlycon-fix-write-combine-mapping-on-x86.patch b/queue-5.4/efi-earlycon-fix-write-combine-mapping-on-x86.patch new file mode 100644 index 00000000000..a48702f0b7b --- /dev/null +++ b/queue-5.4/efi-earlycon-fix-write-combine-mapping-on-x86.patch @@ -0,0 +1,84 @@ +From d92b54570d24d017d2630e314b525ed792f5aa6c Mon Sep 17 00:00:00 2001 +From: Arvind Sankar +Date: Tue, 24 Dec 2019 14:29:07 +0100 +Subject: efi/earlycon: Fix write-combine mapping on x86 + +From: Arvind Sankar + +commit d92b54570d24d017d2630e314b525ed792f5aa6c upstream. + +On x86, until PAT is initialized, WC translates into UC-. Since we +calculate and store pgprot_writecombine(PAGE_KERNEL) when earlycon is +initialized, this means we actually use UC- mappings instead of WC +mappings, which makes scrolling very slow. + +Instead store a boolean flag to indicate whether we want to use +writeback or write-combine mappings, and recalculate the actual pgprot_t +we need on every mapping. Once PAT is initialized, we will start using +write-combine mappings, which speeds up the scrolling considerably. + +Signed-off-by: Arvind Sankar +Signed-off-by: Ard Biesheuvel +Cc: Hans de Goede +Cc: Linus Torvalds +Cc: Peter Zijlstra +Cc: Thomas Gleixner +Cc: linux-efi@vger.kernel.org +Fixes: 69c1f396f25b ("efi/x86: Convert x86 EFI earlyprintk into generic earlycon implementation") +Link: https://lkml.kernel.org/r/20191224132909.102540-2-ardb@kernel.org +Signed-off-by: Ingo Molnar +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/firmware/efi/earlycon.c | 16 +++++++--------- + 1 file changed, 7 insertions(+), 9 deletions(-) + +--- a/drivers/firmware/efi/earlycon.c ++++ b/drivers/firmware/efi/earlycon.c +@@ -17,7 +17,7 @@ static const struct console *earlycon_co + static const struct font_desc *font; + static u32 efi_x, efi_y; + static u64 fb_base; +-static pgprot_t fb_prot; ++static bool fb_wb; + static void *efi_fb; + + /* +@@ -33,10 +33,8 @@ static int __init efi_earlycon_remap_fb( + if (!earlycon_console || !(earlycon_console->flags & CON_ENABLED)) + return 0; + +- if (pgprot_val(fb_prot) == pgprot_val(PAGE_KERNEL)) +- efi_fb = memremap(fb_base, screen_info.lfb_size, MEMREMAP_WB); +- else +- efi_fb = memremap(fb_base, screen_info.lfb_size, MEMREMAP_WC); ++ efi_fb = memremap(fb_base, screen_info.lfb_size, ++ fb_wb ? MEMREMAP_WB : MEMREMAP_WC); + + return efi_fb ? 0 : -ENOMEM; + } +@@ -53,9 +51,12 @@ late_initcall(efi_earlycon_unmap_fb); + + static __ref void *efi_earlycon_map(unsigned long start, unsigned long len) + { ++ pgprot_t fb_prot; ++ + if (efi_fb) + return efi_fb + start; + ++ fb_prot = fb_wb ? PAGE_KERNEL : pgprot_writecombine(PAGE_KERNEL); + return early_memremap_prot(fb_base + start, len, pgprot_val(fb_prot)); + } + +@@ -215,10 +216,7 @@ static int __init efi_earlycon_setup(str + if (screen_info.capabilities & VIDEO_CAPABILITY_64BIT_BASE) + fb_base |= (u64)screen_info.ext_lfb_base << 32; + +- if (opt && !strcmp(opt, "ram")) +- fb_prot = PAGE_KERNEL; +- else +- fb_prot = pgprot_writecombine(PAGE_KERNEL); ++ fb_wb = opt && !strcmp(opt, "ram"); + + si = &screen_info; + xres = si->lfb_width; diff --git a/queue-5.4/locking-lockdep-fix-buffer-overrun-problem-in-stack_trace.patch b/queue-5.4/locking-lockdep-fix-buffer-overrun-problem-in-stack_trace.patch new file mode 100644 index 00000000000..7e8db600415 --- /dev/null +++ b/queue-5.4/locking-lockdep-fix-buffer-overrun-problem-in-stack_trace.patch @@ -0,0 +1,66 @@ +From d91f3057263ceb691ef527e71b41a56b17f6c869 Mon Sep 17 00:00:00 2001 +From: Waiman Long +Date: Fri, 20 Dec 2019 08:51:28 -0500 +Subject: locking/lockdep: Fix buffer overrun problem in stack_trace[] + +From: Waiman Long + +commit d91f3057263ceb691ef527e71b41a56b17f6c869 upstream. + +If the lockdep code is really running out of the stack_trace entries, +it is likely that buffer overrun can happen and the data immediately +after stack_trace[] will be corrupted. + +If there is less than LOCK_TRACE_SIZE_IN_LONGS entries left before +the call to save_trace(), the max_entries computation will leave it +with a very large positive number because of its unsigned nature. The +subsequent call to stack_trace_save() will then corrupt the data after +stack_trace[]. Fix that by changing max_entries to a signed integer +and check for negative value before calling stack_trace_save(). + +Signed-off-by: Waiman Long +Signed-off-by: Peter Zijlstra (Intel) +Reviewed-by: Bart Van Assche +Cc: Linus Torvalds +Cc: Peter Zijlstra +Cc: Thomas Gleixner +Fixes: 12593b7467f9 ("locking/lockdep: Reduce space occupied by stack traces") +Link: https://lkml.kernel.org/r/20191220135128.14876-1-longman@redhat.com +Signed-off-by: Ingo Molnar +Signed-off-by: Greg Kroah-Hartman + +--- + kernel/locking/lockdep.c | 7 +++---- + 1 file changed, 3 insertions(+), 4 deletions(-) + +--- a/kernel/locking/lockdep.c ++++ b/kernel/locking/lockdep.c +@@ -482,7 +482,7 @@ static struct lock_trace *save_trace(voi + struct lock_trace *trace, *t2; + struct hlist_head *hash_head; + u32 hash; +- unsigned int max_entries; ++ int max_entries; + + BUILD_BUG_ON_NOT_POWER_OF_2(STACK_TRACE_HASH_SIZE); + BUILD_BUG_ON(LOCK_TRACE_SIZE_IN_LONGS >= MAX_STACK_TRACE_ENTRIES); +@@ -490,10 +490,8 @@ static struct lock_trace *save_trace(voi + trace = (struct lock_trace *)(stack_trace + nr_stack_trace_entries); + max_entries = MAX_STACK_TRACE_ENTRIES - nr_stack_trace_entries - + LOCK_TRACE_SIZE_IN_LONGS; +- trace->nr_entries = stack_trace_save(trace->entries, max_entries, 3); + +- if (nr_stack_trace_entries >= MAX_STACK_TRACE_ENTRIES - +- LOCK_TRACE_SIZE_IN_LONGS - 1) { ++ if (max_entries <= 0) { + if (!debug_locks_off_graph_unlock()) + return NULL; + +@@ -502,6 +500,7 @@ static struct lock_trace *save_trace(voi + + return NULL; + } ++ trace->nr_entries = stack_trace_save(trace->entries, max_entries, 3); + + hash = jhash(trace->entries, trace->nr_entries * + sizeof(trace->entries[0]), 0); diff --git a/queue-5.4/locking-rwsem-fix-kernel-crash-when-spinning-on-rwsem_owner_unknown.patch b/queue-5.4/locking-rwsem-fix-kernel-crash-when-spinning-on-rwsem_owner_unknown.patch new file mode 100644 index 00000000000..9a57932206d --- /dev/null +++ b/queue-5.4/locking-rwsem-fix-kernel-crash-when-spinning-on-rwsem_owner_unknown.patch @@ -0,0 +1,44 @@ +From 39e7234f00bc93613c086ae42d852d5f4147120a Mon Sep 17 00:00:00 2001 +From: Waiman Long +Date: Wed, 15 Jan 2020 10:43:36 -0500 +Subject: locking/rwsem: Fix kernel crash when spinning on RWSEM_OWNER_UNKNOWN + +From: Waiman Long + +commit 39e7234f00bc93613c086ae42d852d5f4147120a upstream. + +The commit 91d2a812dfb9 ("locking/rwsem: Make handoff writer +optimistically spin on owner") will allow a recently woken up waiting +writer to spin on the owner. Unfortunately, if the owner happens to be +RWSEM_OWNER_UNKNOWN, the code will incorrectly spin on it leading to a +kernel crash. This is fixed by passing the proper non-spinnable bits +to rwsem_spin_on_owner() so that RWSEM_OWNER_UNKNOWN will be treated +as a non-spinnable target. + +Fixes: 91d2a812dfb9 ("locking/rwsem: Make handoff writer optimistically spin on owner") + +Reported-by: Christoph Hellwig +Signed-off-by: Waiman Long +Signed-off-by: Peter Zijlstra (Intel) +Tested-by: Christoph Hellwig +Cc: stable@vger.kernel.org +Link: https://lkml.kernel.org/r/20200115154336.8679-1-longman@redhat.com +Signed-off-by: Greg Kroah-Hartman + +--- + kernel/locking/rwsem.c | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +--- a/kernel/locking/rwsem.c ++++ b/kernel/locking/rwsem.c +@@ -1226,8 +1226,8 @@ wait: + * In this case, we attempt to acquire the lock again + * without sleeping. + */ +- if ((wstate == WRITER_HANDOFF) && +- (rwsem_spin_on_owner(sem, 0) == OWNER_NULL)) ++ if (wstate == WRITER_HANDOFF && ++ rwsem_spin_on_owner(sem, RWSEM_NONSPINNABLE) == OWNER_NULL) + goto trylock_again; + + /* Block until there are no active lockers. */ diff --git a/queue-5.4/mtd-rawnand-gpmi-fix-suspend-resume-problem.patch b/queue-5.4/mtd-rawnand-gpmi-fix-suspend-resume-problem.patch new file mode 100644 index 00000000000..de295ed4d1d --- /dev/null +++ b/queue-5.4/mtd-rawnand-gpmi-fix-suspend-resume-problem.patch @@ -0,0 +1,52 @@ +From 5bc6bb603b4d0c8802af75e4932232683ab2d761 Mon Sep 17 00:00:00 2001 +From: Esben Haabendal +Date: Fri, 17 Jan 2020 21:05:36 +0100 +Subject: mtd: rawnand: gpmi: Fix suspend/resume problem + +From: Esben Haabendal + +commit 5bc6bb603b4d0c8802af75e4932232683ab2d761 upstream. + +On system resume, the gpmi clock must be enabled before accessing gpmi +block. Without this, resume causes something like + +[ 661.348790] gpmi_reset_block(5cbb0f7e): module reset timeout +[ 661.348889] gpmi-nand 1806000.gpmi-nand: Error setting GPMI : -110 +[ 661.348928] PM: dpm_run_callback(): platform_pm_resume+0x0/0x44 returns -110 +[ 661.348961] PM: Device 1806000.gpmi-nand failed to resume: error -110 + +Fixes: ef347c0cfd61 ("mtd: rawnand: gpmi: Implement exec_op") +Cc: stable@vger.kernel.org +Signed-off-by: Esben Haabendal +Acked-by: Han Xu +Signed-off-by: Miquel Raynal +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c | 7 ++++++- + 1 file changed, 6 insertions(+), 1 deletion(-) + +--- a/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c ++++ b/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c +@@ -148,6 +148,10 @@ static int gpmi_init(struct gpmi_nand_da + struct resources *r = &this->resources; + int ret; + ++ ret = pm_runtime_get_sync(this->dev); ++ if (ret < 0) ++ return ret; ++ + ret = gpmi_reset_block(r->gpmi_regs, false); + if (ret) + goto err_out; +@@ -179,8 +183,9 @@ static int gpmi_init(struct gpmi_nand_da + */ + writel(BM_GPMI_CTRL1_DECOUPLE_CS, r->gpmi_regs + HW_GPMI_CTRL1_SET); + +- return 0; + err_out: ++ pm_runtime_mark_last_busy(this->dev); ++ pm_runtime_put_autosuspend(this->dev); + return ret; + } + diff --git a/queue-5.4/mtd-rawnand-gpmi-restore-nfc-timing-setup-after-suspend-resume.patch b/queue-5.4/mtd-rawnand-gpmi-restore-nfc-timing-setup-after-suspend-resume.patch new file mode 100644 index 00000000000..60be64fd191 --- /dev/null +++ b/queue-5.4/mtd-rawnand-gpmi-restore-nfc-timing-setup-after-suspend-resume.patch @@ -0,0 +1,37 @@ +From d70486668cdf51b14a50425ab45fc18677a167b2 Mon Sep 17 00:00:00 2001 +From: Esben Haabendal +Date: Fri, 17 Jan 2020 21:05:37 +0100 +Subject: mtd: rawnand: gpmi: Restore nfc timing setup after suspend/resume + +From: Esben Haabendal + +commit d70486668cdf51b14a50425ab45fc18677a167b2 upstream. + +As we reset the GPMI block at resume, the timing parameters setup by a +previous exec_op is lost. Rewriting GPMI timing registers on first exec_op +after resume fixes the problem. + +Fixes: ef347c0cfd61 ("mtd: rawnand: gpmi: Implement exec_op") +Cc: stable@vger.kernel.org +Signed-off-by: Esben Haabendal +Acked-by: Han Xu +Signed-off-by: Miquel Raynal +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c | 4 ++++ + 1 file changed, 4 insertions(+) + +--- a/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c ++++ b/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c +@@ -2727,6 +2727,10 @@ static int gpmi_pm_resume(struct device + return ret; + } + ++ /* Set flag to get timing setup restored for next exec_op */ ++ if (this->hw.clk_rate) ++ this->hw.must_apply_timings = true; ++ + /* re-init the BCH registers */ + ret = bch_set_geometry(this); + if (ret) { diff --git a/queue-5.4/mtd-spi-nor-fix-selection-of-4-byte-addressing-opcodes-on-spansion.patch b/queue-5.4/mtd-spi-nor-fix-selection-of-4-byte-addressing-opcodes-on-spansion.patch new file mode 100644 index 00000000000..5e2ca4a9a76 --- /dev/null +++ b/queue-5.4/mtd-spi-nor-fix-selection-of-4-byte-addressing-opcodes-on-spansion.patch @@ -0,0 +1,39 @@ +From 440b6d50254bdbd84c2a665c7f53ec69dd741a4f Mon Sep 17 00:00:00 2001 +From: Vignesh Raghavendra +Date: Wed, 8 Jan 2020 10:43:43 +0530 +Subject: mtd: spi-nor: Fix selection of 4-byte addressing opcodes on Spansion + +From: Vignesh Raghavendra + +commit 440b6d50254bdbd84c2a665c7f53ec69dd741a4f upstream. + +mtd->size is still unassigned when running spansion_post_sfdp_fixups() +hook, therefore use nor->params.size to determine the size of flash device. + +This makes sure that 4-byte addressing opcodes are used on Spansion +flashes that are larger than 16MiB and don't have SFDP 4BAIT table +populated. + +Fixes: 92094ebc385e ("mtd: spi-nor: Add spansion_post_sfdp_fixups()") +Signed-off-by: Vignesh Raghavendra +Reviewed-by: Tudor Ambarus +Signed-off-by: Miquel Raynal +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/mtd/spi-nor/spi-nor.c | 4 +--- + 1 file changed, 1 insertion(+), 3 deletions(-) + +--- a/drivers/mtd/spi-nor/spi-nor.c ++++ b/drivers/mtd/spi-nor/spi-nor.c +@@ -4544,9 +4544,7 @@ static void spi_nor_info_init_params(str + + static void spansion_post_sfdp_fixups(struct spi_nor *nor) + { +- struct mtd_info *mtd = &nor->mtd; +- +- if (mtd->size <= SZ_16M) ++ if (nor->params.size <= SZ_16M) + return; + + nor->flags |= SNOR_F_4B_OPCODES; diff --git a/queue-5.4/perf-hists-fix-variable-name-s-inconsistency-in-hists__for_each-macro.patch b/queue-5.4/perf-hists-fix-variable-name-s-inconsistency-in-hists__for_each-macro.patch new file mode 100644 index 00000000000..3a1373cfcda --- /dev/null +++ b/queue-5.4/perf-hists-fix-variable-name-s-inconsistency-in-hists__for_each-macro.patch @@ -0,0 +1,45 @@ +From 55347ec340af401437680fd0e88df6739a967f9f Mon Sep 17 00:00:00 2001 +From: Yuya Fujita +Date: Thu, 19 Dec 2019 08:08:32 +0000 +Subject: perf hists: Fix variable name's inconsistency in hists__for_each() macro + +From: Yuya Fujita + +commit 55347ec340af401437680fd0e88df6739a967f9f upstream. + +Variable names are inconsistent in hists__for_each macro(). + +Due to this inconsistency, the macro replaces its second argument with +"fmt" regardless of its original name. + +So far it works because only "fmt" is passed to the second argument. +However, this behavior is not expected and should be fixed. + +Fixes: f0786af536bb ("perf hists: Introduce hists__for_each_format macro") +Fixes: aa6f50af822a ("perf hists: Introduce hists__for_each_sort_list macro") +Signed-off-by: Yuya Fujita +Acked-by: Jiri Olsa +Cc: Peter Zijlstra +Link: http://lore.kernel.org/lkml/OSAPR01MB1588E1C47AC22043175DE1B2E8520@OSAPR01MB1588.jpnprd01.prod.outlook.com +Signed-off-by: Arnaldo Carvalho de Melo +Signed-off-by: Greg Kroah-Hartman + +--- + tools/perf/util/hist.h | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +--- a/tools/perf/util/hist.h ++++ b/tools/perf/util/hist.h +@@ -339,10 +339,10 @@ static inline void perf_hpp__prepend_sor + list_for_each_entry_safe(format, tmp, &(_list)->sorts, sort_list) + + #define hists__for_each_format(hists, format) \ +- perf_hpp_list__for_each_format((hists)->hpp_list, fmt) ++ perf_hpp_list__for_each_format((hists)->hpp_list, format) + + #define hists__for_each_sort_list(hists, format) \ +- perf_hpp_list__for_each_sort_list((hists)->hpp_list, fmt) ++ perf_hpp_list__for_each_sort_list((hists)->hpp_list, format) + + extern struct perf_hpp_fmt perf_hpp__format[]; + diff --git a/queue-5.4/perf-report-fix-incorrectly-added-dimensions-as-switch-perf-data-file.patch b/queue-5.4/perf-report-fix-incorrectly-added-dimensions-as-switch-perf-data-file.patch new file mode 100644 index 00000000000..6ea7bed9328 --- /dev/null +++ b/queue-5.4/perf-report-fix-incorrectly-added-dimensions-as-switch-perf-data-file.patch @@ -0,0 +1,69 @@ +From 0feba17bd7ee3b7e03d141f119049dcc23efa94e Mon Sep 17 00:00:00 2001 +From: Jin Yao +Date: Fri, 20 Dec 2019 09:37:19 +0800 +Subject: perf report: Fix incorrectly added dimensions as switch perf data file + +From: Jin Yao + +commit 0feba17bd7ee3b7e03d141f119049dcc23efa94e upstream. + +We observed an issue that was some extra columns displayed after switching +perf data file in browser. The steps to reproduce: + +1. perf record -a -e cycles,instructions -- sleep 3 +2. perf report --group +3. In browser, we use hotkey 's' to switch to another perf.data +4. Now in browser, the extra columns 'Self' and 'Children' are displayed. + +The issue is setup_sorting() executed again after repeat path, so dimensions +are added again. + +This patch checks the last key returned from __cmd_report(). If it's +K_SWITCH_INPUT_DATA, skips the setup_sorting(). + +Fixes: ad0de0971b7f ("perf report: Enable the runtime switching of perf data file") +Signed-off-by: Jin Yao +Tested-by: Arnaldo Carvalho de Melo +Acked-by: Jiri Olsa +Cc: Alexander Shishkin +Cc: Andi Kleen +Cc: Feng Tang +Cc: Jin Yao +Cc: Kan Liang +Cc: Peter Zijlstra +Link: http://lore.kernel.org/lkml/20191220013722.20592-1-yao.jin@linux.intel.com +Signed-off-by: Arnaldo Carvalho de Melo +Signed-off-by: Greg Kroah-Hartman + +--- + tools/perf/builtin-report.c | 5 ++++- + 1 file changed, 4 insertions(+), 1 deletion(-) + +--- a/tools/perf/builtin-report.c ++++ b/tools/perf/builtin-report.c +@@ -1031,6 +1031,7 @@ int cmd_report(int argc, const char **ar + struct stat st; + bool has_br_stack = false; + int branch_mode = -1; ++ int last_key = 0; + bool branch_call_mode = false; + #define CALLCHAIN_DEFAULT_OPT "graph,0.5,caller,function,percent" + static const char report_callchain_help[] = "Display call graph (stack chain/backtrace):\n\n" +@@ -1396,7 +1397,8 @@ repeat: + sort_order = sort_tmp; + } + +- if (setup_sorting(session->evlist) < 0) { ++ if ((last_key != K_SWITCH_INPUT_DATA) && ++ (setup_sorting(session->evlist) < 0)) { + if (sort_order) + parse_options_usage(report_usage, options, "s", 1); + if (field_order) +@@ -1475,6 +1477,7 @@ repeat: + ret = __cmd_report(&report); + if (ret == K_SWITCH_INPUT_DATA) { + perf_session__delete(session); ++ last_key = K_SWITCH_INPUT_DATA; + goto repeat; + } else + ret = 0; diff --git a/queue-5.4/perf-x86-intel-uncore-fix-missing-marker-for-snr_uncore_imc_freerunning_events.patch b/queue-5.4/perf-x86-intel-uncore-fix-missing-marker-for-snr_uncore_imc_freerunning_events.patch new file mode 100644 index 00000000000..6e02e5a6532 --- /dev/null +++ b/queue-5.4/perf-x86-intel-uncore-fix-missing-marker-for-snr_uncore_imc_freerunning_events.patch @@ -0,0 +1,37 @@ +From fa694ae532836bd2f4cd659e9b4032abaf9fa9e5 Mon Sep 17 00:00:00 2001 +From: Kan Liang +Date: Thu, 16 Jan 2020 12:02:09 -0800 +Subject: perf/x86/intel/uncore: Fix missing marker for snr_uncore_imc_freerunning_events + +From: Kan Liang + +commit fa694ae532836bd2f4cd659e9b4032abaf9fa9e5 upstream. + +An Oops during the boot is found on some SNR machines. It turns out +this is because the snr_uncore_imc_freerunning_events[] array was +missing an end-marker. + +Fixes: ee49532b38dd ("perf/x86/intel/uncore: Add IMC uncore support for Snow Ridge") +Reported-by: Like Xu +Signed-off-by: Kan Liang +Signed-off-by: Peter Zijlstra (Intel) +Signed-off-by: Ingo Molnar +Tested-by: Like Xu +Cc: stable@vger.kernel.org +Link: https://lkml.kernel.org/r/20200116200210.18937-1-kan.liang@linux.intel.com +Signed-off-by: Greg Kroah-Hartman + +--- + arch/x86/events/intel/uncore_snbep.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/arch/x86/events/intel/uncore_snbep.c ++++ b/arch/x86/events/intel/uncore_snbep.c +@@ -4536,6 +4536,7 @@ static struct uncore_event_desc snr_unco + INTEL_UNCORE_EVENT_DESC(write, "event=0xff,umask=0x21"), + INTEL_UNCORE_EVENT_DESC(write.scale, "3.814697266e-6"), + INTEL_UNCORE_EVENT_DESC(write.unit, "MiB"), ++ { /* end: all zeroes */ }, + }; + + static struct intel_uncore_ops snr_uncore_imc_freerunning_ops = { diff --git a/queue-5.4/ptrace-reintroduce-usage-of-subjective-credentials-in-ptrace_has_cap.patch b/queue-5.4/ptrace-reintroduce-usage-of-subjective-credentials-in-ptrace_has_cap.patch new file mode 100644 index 00000000000..284dd97f2d6 --- /dev/null +++ b/queue-5.4/ptrace-reintroduce-usage-of-subjective-credentials-in-ptrace_has_cap.patch @@ -0,0 +1,100 @@ +From 6b3ad6649a4c75504edeba242d3fd36b3096a57f Mon Sep 17 00:00:00 2001 +From: Christian Brauner +Date: Wed, 15 Jan 2020 14:42:34 +0100 +Subject: ptrace: reintroduce usage of subjective credentials in ptrace_has_cap() + +From: Christian Brauner + +commit 6b3ad6649a4c75504edeba242d3fd36b3096a57f upstream. + +Commit 69f594a38967 ("ptrace: do not audit capability check when outputing /proc/pid/stat") +introduced the ability to opt out of audit messages for accesses to various +proc files since they are not violations of policy. While doing so it +somehow switched the check from ns_capable() to +has_ns_capability{_noaudit}(). That means it switched from checking the +subjective credentials of the task to using the objective credentials. This +is wrong since. ptrace_has_cap() is currently only used in +ptrace_may_access() And is used to check whether the calling task (subject) +has the CAP_SYS_PTRACE capability in the provided user namespace to operate +on the target task (object). According to the cred.h comments this would +mean the subjective credentials of the calling task need to be used. +This switches ptrace_has_cap() to use security_capable(). Because we only +call ptrace_has_cap() in ptrace_may_access() and in there we already have a +stable reference to the calling task's creds under rcu_read_lock() there's +no need to go through another series of dereferences and rcu locking done +in ns_capable{_noaudit}(). + +As one example where this might be particularly problematic, Jann pointed +out that in combination with the upcoming IORING_OP_OPENAT feature, this +bug might allow unprivileged users to bypass the capability checks while +asynchronously opening files like /proc/*/mem, because the capability +checks for this would be performed against kernel credentials. + +To illustrate on the former point about this being exploitable: When +io_uring creates a new context it records the subjective credentials of the +caller. Later on, when it starts to do work it creates a kernel thread and +registers a callback. The callback runs with kernel creds for +ktask->real_cred and ktask->cred. To prevent this from becoming a +full-blown 0-day io_uring will call override_cred() and override +ktask->cred with the subjective credentials of the creator of the io_uring +instance. With ptrace_has_cap() currently looking at ktask->real_cred this +override will be ineffective and the caller will be able to open arbitray +proc files as mentioned above. +Luckily, this is currently not exploitable but will turn into a 0-day once +IORING_OP_OPENAT{2} land in v5.6. Fix it now! + +Cc: Oleg Nesterov +Cc: Eric Paris +Cc: stable@vger.kernel.org +Reviewed-by: Kees Cook +Reviewed-by: Serge Hallyn +Reviewed-by: Jann Horn +Fixes: 69f594a38967 ("ptrace: do not audit capability check when outputing /proc/pid/stat") +Signed-off-by: Christian Brauner +Signed-off-by: Greg Kroah-Hartman + +--- + kernel/ptrace.c | 15 ++++++++++----- + 1 file changed, 10 insertions(+), 5 deletions(-) + +--- a/kernel/ptrace.c ++++ b/kernel/ptrace.c +@@ -264,12 +264,17 @@ static int ptrace_check_attach(struct ta + return ret; + } + +-static int ptrace_has_cap(struct user_namespace *ns, unsigned int mode) ++static bool ptrace_has_cap(const struct cred *cred, struct user_namespace *ns, ++ unsigned int mode) + { ++ int ret; ++ + if (mode & PTRACE_MODE_NOAUDIT) +- return has_ns_capability_noaudit(current, ns, CAP_SYS_PTRACE); ++ ret = security_capable(cred, ns, CAP_SYS_PTRACE, CAP_OPT_NOAUDIT); + else +- return has_ns_capability(current, ns, CAP_SYS_PTRACE); ++ ret = security_capable(cred, ns, CAP_SYS_PTRACE, CAP_OPT_NONE); ++ ++ return ret == 0; + } + + /* Returns 0 on success, -errno on denial. */ +@@ -321,7 +326,7 @@ static int __ptrace_may_access(struct ta + gid_eq(caller_gid, tcred->sgid) && + gid_eq(caller_gid, tcred->gid)) + goto ok; +- if (ptrace_has_cap(tcred->user_ns, mode)) ++ if (ptrace_has_cap(cred, tcred->user_ns, mode)) + goto ok; + rcu_read_unlock(); + return -EPERM; +@@ -340,7 +345,7 @@ ok: + mm = task->mm; + if (mm && + ((get_dumpable(mm) != SUID_DUMP_USER) && +- !ptrace_has_cap(mm->user_ns, mode))) ++ !ptrace_has_cap(cred, mm->user_ns, mode))) + return -EPERM; + + return security_ptrace_access_check(task, mode); diff --git a/queue-5.4/s390-setup-fix-secure-ipl-message.patch b/queue-5.4/s390-setup-fix-secure-ipl-message.patch new file mode 100644 index 00000000000..6159faab325 --- /dev/null +++ b/queue-5.4/s390-setup-fix-secure-ipl-message.patch @@ -0,0 +1,34 @@ +From 40260b01d029ba374637838213af500e03305326 Mon Sep 17 00:00:00 2001 +From: Philipp Rudo +Date: Wed, 18 Dec 2019 11:24:43 +0100 +Subject: s390/setup: Fix secure ipl message + +From: Philipp Rudo + +commit 40260b01d029ba374637838213af500e03305326 upstream. + +The new machine loader on z15 always creates an IPL Report block and +thus sets the IPL_PL_FLAG_IPLSR even when secure boot is disabled. This +causes the wrong message being printed at boot. Fix this by checking for +IPL_PL_FLAG_SIPL instead. + +Fixes: 9641b8cc733f ("s390/ipl: read IPL report at early boot") +Signed-off-by: Philipp Rudo +Signed-off-by: Vasily Gorbik +Signed-off-by: Greg Kroah-Hartman + +--- + arch/s390/kernel/setup.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/arch/s390/kernel/setup.c ++++ b/arch/s390/kernel/setup.c +@@ -1059,7 +1059,7 @@ static void __init log_component_list(vo + + if (!early_ipl_comp_list_addr) + return; +- if (ipl_block.hdr.flags & IPL_PL_FLAG_IPLSR) ++ if (ipl_block.hdr.flags & IPL_PL_FLAG_SIPL) + pr_info("Linux is running with Secure-IPL enabled\n"); + else + pr_info("Linux is running with Secure-IPL disabled\n"); diff --git a/queue-5.4/s390-zcrypt-fix-cca-cipher-key-gen-with-clear-key-value-function.patch b/queue-5.4/s390-zcrypt-fix-cca-cipher-key-gen-with-clear-key-value-function.patch new file mode 100644 index 00000000000..62ff098875a --- /dev/null +++ b/queue-5.4/s390-zcrypt-fix-cca-cipher-key-gen-with-clear-key-value-function.patch @@ -0,0 +1,38 @@ +From 94dd3bada53ee77b80d0aeee5571eeb83654d156 Mon Sep 17 00:00:00 2001 +From: Harald Freudenberger +Date: Fri, 20 Dec 2019 09:06:09 +0100 +Subject: s390/zcrypt: Fix CCA cipher key gen with clear key value function + +From: Harald Freudenberger + +commit 94dd3bada53ee77b80d0aeee5571eeb83654d156 upstream. + +Regression tests showed that the CCA cipher key function which +generates an CCA cipher key with given clear key value does not work +correctly. At parsing the reply CPRB two limits are wrong calculated +resulting in rejecting the reply as invalid with s390dbf message +"_ip_cprb_helper reply with invalid or unknown key block". + +Fixes: f2bbc96e7cfa ("s390/pkey: add CCA AES cipher key support") +Cc: Stable +Signed-off-by: Harald Freudenberger +Signed-off-by: Vasily Gorbik +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/s390/crypto/zcrypt_ccamisc.c | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +--- a/drivers/s390/crypto/zcrypt_ccamisc.c ++++ b/drivers/s390/crypto/zcrypt_ccamisc.c +@@ -1037,8 +1037,8 @@ static int _ip_cprb_helper(u16 cardnr, u + prepparm = (struct iprepparm *) prepcblk->rpl_parmb; + + /* do some plausibility checks on the key block */ +- if (prepparm->kb.len < 120 + 5 * sizeof(uint16_t) || +- prepparm->kb.len > 136 + 5 * sizeof(uint16_t)) { ++ if (prepparm->kb.len < 120 + 3 * sizeof(uint16_t) || ++ prepparm->kb.len > 136 + 3 * sizeof(uint16_t)) { + DEBUG_ERR("%s reply with invalid or unknown key block\n", + __func__); + rc = -EIO; diff --git a/queue-5.4/scsi-storvsc-correctly-set-number-of-hardware-queues-for-ide-disk.patch b/queue-5.4/scsi-storvsc-correctly-set-number-of-hardware-queues-for-ide-disk.patch new file mode 100644 index 00000000000..db8154757a9 --- /dev/null +++ b/queue-5.4/scsi-storvsc-correctly-set-number-of-hardware-queues-for-ide-disk.patch @@ -0,0 +1,44 @@ +From 7b571c19d4c0b78d27dd3bf1f3c42e4032390af6 Mon Sep 17 00:00:00 2001 +From: Long Li +Date: Mon, 13 Jan 2020 16:08:36 -0800 +Subject: scsi: storvsc: Correctly set number of hardware queues for IDE disk + +From: Long Li + +commit 7b571c19d4c0b78d27dd3bf1f3c42e4032390af6 upstream. + +Commit 0ed881027690 ("scsi: storvsc: setup 1:1 mapping between hardware +queue and CPU queue") introduced a regression for disks attached to +IDE. For these disks the host VSP only offers one VMBUS channel. Setting +multiple queues can overload the VMBUS channel and result in performance +drop for high queue depth workload on system with large number of CPUs. + +Fix it by leaving the number of hardware queues to 1 (default value) for +IDE disks. + +Fixes: 0ed881027690 ("scsi: storvsc: setup 1:1 mapping between hardware queue and CPU queue") +Link: https://lore.kernel.org/r/1578960516-108228-1-git-send-email-longli@linuxonhyperv.com +Reviewed-by: Ming Lei +Signed-off-by: Long Li +Signed-off-by: Martin K. Petersen +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/scsi/storvsc_drv.c | 4 +++- + 1 file changed, 3 insertions(+), 1 deletion(-) + +--- a/drivers/scsi/storvsc_drv.c ++++ b/drivers/scsi/storvsc_drv.c +@@ -1835,9 +1835,11 @@ static int storvsc_probe(struct hv_devic + */ + host->sg_tablesize = (stor_device->max_transfer_bytes >> PAGE_SHIFT); + /* ++ * For non-IDE disks, the host supports multiple channels. + * Set the number of HW queues we are supporting. + */ +- host->nr_hw_queues = num_present_cpus(); ++ if (!dev_is_ide) ++ host->nr_hw_queues = num_present_cpus(); + + /* + * Set the error handler work queue. diff --git a/queue-5.4/series b/queue-5.4/series index 6fc508855fc..d1378be9b41 100644 --- a/queue-5.4/series +++ b/queue-5.4/series @@ -54,3 +54,24 @@ staging-comedi-ni_routes-fix-null-dereference-in-ni_find_route_source.patch staging-comedi-ni_routes-allow-partial-routing-information.patch scsi-fnic-fix-invalid-stack-access.patch scsi-mptfusion-fix-double-fetch-bug-in-ioctl.patch +ptrace-reintroduce-usage-of-subjective-credentials-in-ptrace_has_cap.patch +mtd-rawnand-gpmi-fix-suspend-resume-problem.patch +mtd-rawnand-gpmi-restore-nfc-timing-setup-after-suspend-resume.patch +usb-core-hub-improved-device-recognition-on-remote-wakeup.patch +cpu-smt-fix-x86-link-error-without-config_sysfs.patch +x86-resctrl-fix-an-imbalance-in-domain_remove_cpu.patch +x86-cpu-amd-ensure-clearing-of-sme-sev-features-is-maintained.patch +locking-rwsem-fix-kernel-crash-when-spinning-on-rwsem_owner_unknown.patch +perf-x86-intel-uncore-fix-missing-marker-for-snr_uncore_imc_freerunning_events.patch +x86-efistub-disable-paging-at-mixed-mode-entry.patch +s390-zcrypt-fix-cca-cipher-key-gen-with-clear-key-value-function.patch +scsi-storvsc-correctly-set-number-of-hardware-queues-for-ide-disk.patch +mtd-spi-nor-fix-selection-of-4-byte-addressing-opcodes-on-spansion.patch +drm-i915-add-missing-include-file-linux-math64.h.patch +x86-resctrl-fix-potential-memory-leak.patch +efi-earlycon-fix-write-combine-mapping-on-x86.patch +s390-setup-fix-secure-ipl-message.patch +clk-samsung-exynos5420-keep-top-g3d-clocks-enabled.patch +perf-hists-fix-variable-name-s-inconsistency-in-hists__for_each-macro.patch +locking-lockdep-fix-buffer-overrun-problem-in-stack_trace.patch +perf-report-fix-incorrectly-added-dimensions-as-switch-perf-data-file.patch diff --git a/queue-5.4/usb-core-hub-improved-device-recognition-on-remote-wakeup.patch b/queue-5.4/usb-core-hub-improved-device-recognition-on-remote-wakeup.patch new file mode 100644 index 00000000000..b266fba6c8f --- /dev/null +++ b/queue-5.4/usb-core-hub-improved-device-recognition-on-remote-wakeup.patch @@ -0,0 +1,65 @@ +From 9c06ac4c83df6d6fbdbf7488fbad822b4002ba19 Mon Sep 17 00:00:00 2001 +From: Keiya Nobuta +Date: Thu, 9 Jan 2020 14:14:48 +0900 +Subject: usb: core: hub: Improved device recognition on remote wakeup + +From: Keiya Nobuta + +commit 9c06ac4c83df6d6fbdbf7488fbad822b4002ba19 upstream. + +If hub_activate() is called before D+ has stabilized after remote +wakeup, the following situation might occur: + + __ ___________________ + / \ / +D+ __/ \__/ + +Hub _______________________________ + | ^ ^ ^ + | | | | +Host _____v__|___|___________|______ + | | | | + | | | \-- Interrupt Transfer (*3) + | | \-- ClearPortFeature (*2) + | \-- GetPortStatus (*1) + \-- Host detects remote wakeup + +- D+ goes high, Host starts running by remote wakeup +- D+ is not stable, goes low +- Host requests GetPortStatus at (*1) and gets the following hub status: + - Current Connect Status bit is 0 + - Connect Status Change bit is 1 +- D+ stabilizes, goes high +- Host requests ClearPortFeature and thus Connect Status Change bit is + cleared at (*2) +- After waiting 100 ms, Host starts the Interrupt Transfer at (*3) +- Since the Connect Status Change bit is 0, Hub returns NAK. + +In this case, port_event() is not called in hub_event() and Host cannot +recognize device. To solve this issue, flag change_bits even if only +Connect Status Change bit is 1 when got in the first GetPortStatus. + +This issue occurs rarely because it only if D+ changes during a very +short time between GetPortStatus and ClearPortFeature. However, it is +fatal if it occurs in embedded system. + +Signed-off-by: Keiya Nobuta +Cc: stable +Acked-by: Alan Stern +Link: https://lore.kernel.org/r/20200109051448.28150-1-nobuta.keiya@fujitsu.com +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/usb/core/hub.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/drivers/usb/core/hub.c ++++ b/drivers/usb/core/hub.c +@@ -1191,6 +1191,7 @@ static void hub_activate(struct usb_hub + * PORT_OVER_CURRENT is not. So check for any of them. + */ + if (udev || (portstatus & USB_PORT_STAT_CONNECTION) || ++ (portchange & USB_PORT_STAT_C_CONNECTION) || + (portstatus & USB_PORT_STAT_OVERCURRENT) || + (portchange & USB_PORT_STAT_C_OVERCURRENT)) + set_bit(port1, hub->change_bits); diff --git a/queue-5.4/x86-cpu-amd-ensure-clearing-of-sme-sev-features-is-maintained.patch b/queue-5.4/x86-cpu-amd-ensure-clearing-of-sme-sev-features-is-maintained.patch new file mode 100644 index 00000000000..2243026b75c --- /dev/null +++ b/queue-5.4/x86-cpu-amd-ensure-clearing-of-sme-sev-features-is-maintained.patch @@ -0,0 +1,41 @@ +From a006483b2f97af685f0e60f3a547c9ad4c9b9e94 Mon Sep 17 00:00:00 2001 +From: Tom Lendacky +Date: Wed, 15 Jan 2020 16:05:16 -0600 +Subject: x86/CPU/AMD: Ensure clearing of SME/SEV features is maintained + +From: Tom Lendacky + +commit a006483b2f97af685f0e60f3a547c9ad4c9b9e94 upstream. + +If the SME and SEV features are present via CPUID, but memory encryption +support is not enabled (MSR 0xC001_0010[23]), the feature flags are cleared +using clear_cpu_cap(). However, if get_cpu_cap() is later called, these +feature flags will be reset back to present, which is not desired. + +Change from using clear_cpu_cap() to setup_clear_cpu_cap() so that the +clearing of the flags is maintained. + +Signed-off-by: Tom Lendacky +Signed-off-by: Borislav Petkov +Cc: # 4.16.x- +Link: https://lkml.kernel.org/r/226de90a703c3c0be5a49565047905ac4e94e8f3.1579125915.git.thomas.lendacky@amd.com +Signed-off-by: Greg Kroah-Hartman + +--- + arch/x86/kernel/cpu/amd.c | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +--- a/arch/x86/kernel/cpu/amd.c ++++ b/arch/x86/kernel/cpu/amd.c +@@ -615,9 +615,9 @@ static void early_detect_mem_encrypt(str + return; + + clear_all: +- clear_cpu_cap(c, X86_FEATURE_SME); ++ setup_clear_cpu_cap(X86_FEATURE_SME); + clear_sev: +- clear_cpu_cap(c, X86_FEATURE_SEV); ++ setup_clear_cpu_cap(X86_FEATURE_SEV); + } + } + diff --git a/queue-5.4/x86-efistub-disable-paging-at-mixed-mode-entry.patch b/queue-5.4/x86-efistub-disable-paging-at-mixed-mode-entry.patch new file mode 100644 index 00000000000..83485f7e3e7 --- /dev/null +++ b/queue-5.4/x86-efistub-disable-paging-at-mixed-mode-entry.patch @@ -0,0 +1,46 @@ +From 4911ee401b7ceff8f38e0ac597cbf503d71e690c Mon Sep 17 00:00:00 2001 +From: Ard Biesheuvel +Date: Tue, 24 Dec 2019 14:29:09 +0100 +Subject: x86/efistub: Disable paging at mixed mode entry + +From: Ard Biesheuvel + +commit 4911ee401b7ceff8f38e0ac597cbf503d71e690c upstream. + +The EFI mixed mode entry code goes through the ordinary startup_32() +routine before jumping into the kernel's EFI boot code in 64-bit +mode. The 32-bit startup code must be entered with paging disabled, +but this is not documented as a requirement for the EFI handover +protocol, and so we should disable paging explicitly when entering +the kernel from 32-bit EFI firmware. + +Signed-off-by: Ard Biesheuvel +Cc: +Cc: Arvind Sankar +Cc: Hans de Goede +Cc: Linus Torvalds +Cc: Peter Zijlstra +Cc: Thomas Gleixner +Cc: linux-efi@vger.kernel.org +Link: https://lkml.kernel.org/r/20191224132909.102540-4-ardb@kernel.org +Signed-off-by: Ingo Molnar +Signed-off-by: Greg Kroah-Hartman + +--- + arch/x86/boot/compressed/head_64.S | 5 +++++ + 1 file changed, 5 insertions(+) + +--- a/arch/x86/boot/compressed/head_64.S ++++ b/arch/x86/boot/compressed/head_64.S +@@ -244,6 +244,11 @@ ENTRY(efi32_stub_entry) + leal efi32_config(%ebp), %eax + movl %eax, efi_config(%ebp) + ++ /* Disable paging */ ++ movl %cr0, %eax ++ btrl $X86_CR0_PG_BIT, %eax ++ movl %eax, %cr0 ++ + jmp startup_32 + ENDPROC(efi32_stub_entry) + #endif diff --git a/queue-5.4/x86-resctrl-fix-an-imbalance-in-domain_remove_cpu.patch b/queue-5.4/x86-resctrl-fix-an-imbalance-in-domain_remove_cpu.patch new file mode 100644 index 00000000000..5626e49ce9a --- /dev/null +++ b/queue-5.4/x86-resctrl-fix-an-imbalance-in-domain_remove_cpu.patch @@ -0,0 +1,75 @@ +From e278af89f1ba0a9ef20947db6afc2c9afa37e85b Mon Sep 17 00:00:00 2001 +From: Qian Cai +Date: Tue, 10 Dec 2019 22:30:42 -0500 +Subject: x86/resctrl: Fix an imbalance in domain_remove_cpu() + +From: Qian Cai + +commit e278af89f1ba0a9ef20947db6afc2c9afa37e85b upstream. + +A system that supports resource monitoring may have multiple resources +while not all of these resources are capable of monitoring. Monitoring +related state is initialized only for resources that are capable of +monitoring and correspondingly this state should subsequently only be +removed from these resources that are capable of monitoring. + +domain_add_cpu() calls domain_setup_mon_state() only when r->mon_capable +is true where it will initialize d->mbm_over. However, +domain_remove_cpu() calls cancel_delayed_work(&d->mbm_over) without +checking r->mon_capable resulting in an attempt to cancel d->mbm_over on +all resources, even those that never initialized d->mbm_over because +they are not capable of monitoring. Hence, it triggers a debugobjects +warning when offlining CPUs because those timer debugobjects are never +initialized: + + ODEBUG: assert_init not available (active state 0) object type: + timer_list hint: 0x0 + WARNING: CPU: 143 PID: 789 at lib/debugobjects.c:484 + debug_print_object + Hardware name: HP Synergy 680 Gen9/Synergy 680 Gen9 Compute Module, BIOS I40 05/23/2018 + RIP: 0010:debug_print_object + Call Trace: + debug_object_assert_init + del_timer + try_to_grab_pending + cancel_delayed_work + resctrl_offline_cpu + cpuhp_invoke_callback + cpuhp_thread_fun + smpboot_thread_fn + kthread + ret_from_fork + +Fixes: e33026831bdb ("x86/intel_rdt/mbm: Handle counter overflow") +Signed-off-by: Qian Cai +Signed-off-by: Borislav Petkov +Acked-by: Reinette Chatre +Cc: Fenghua Yu +Cc: "H. Peter Anvin" +Cc: Ingo Molnar +Cc: john.stultz@linaro.org +Cc: sboyd@kernel.org +Cc: +Cc: Thomas Gleixner +Cc: tj@kernel.org +Cc: Tony Luck +Cc: Vikas Shivappa +Cc: x86-ml +Link: https://lkml.kernel.org/r/20191211033042.2188-1-cai@lca.pw +Signed-off-by: Greg Kroah-Hartman + +--- + arch/x86/kernel/cpu/resctrl/core.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/arch/x86/kernel/cpu/resctrl/core.c ++++ b/arch/x86/kernel/cpu/resctrl/core.c +@@ -618,7 +618,7 @@ static void domain_remove_cpu(int cpu, s + if (static_branch_unlikely(&rdt_mon_enable_key)) + rmdir_mondata_subdir_allrdtgrp(r, d->id); + list_del(&d->list); +- if (is_mbm_enabled()) ++ if (r->mon_capable && is_mbm_enabled()) + cancel_delayed_work(&d->mbm_over); + if (is_llc_occupancy_enabled() && has_busy_rmid(r, d)) { + /* diff --git a/queue-5.4/x86-resctrl-fix-potential-memory-leak.patch b/queue-5.4/x86-resctrl-fix-potential-memory-leak.patch new file mode 100644 index 00000000000..2f95cfd62b0 --- /dev/null +++ b/queue-5.4/x86-resctrl-fix-potential-memory-leak.patch @@ -0,0 +1,54 @@ +From ab6a2114433a3b5b555983dcb9b752a85255f04b Mon Sep 17 00:00:00 2001 +From: Shakeel Butt +Date: Thu, 2 Jan 2020 08:58:44 -0800 +Subject: x86/resctrl: Fix potential memory leak + +From: Shakeel Butt + +commit ab6a2114433a3b5b555983dcb9b752a85255f04b upstream. + +set_cache_qos_cfg() is leaking memory when the given level is not +RDT_RESOURCE_L3 or RDT_RESOURCE_L2. At the moment, this function is +called with only valid levels but move the allocation after the valid +level checks in order to make it more robust and future proof. + + [ bp: Massage commit message. ] + +Fixes: 99adde9b370de ("x86/intel_rdt: Enable L2 CDP in MSR IA32_L2_QOS_CFG") +Signed-off-by: Shakeel Butt +Signed-off-by: Borislav Petkov +Cc: Fenghua Yu +Cc: "H. Peter Anvin" +Cc: Ingo Molnar +Cc: Reinette Chatre +Cc: Thomas Gleixner +Cc: x86-ml +Link: https://lkml.kernel.org/r/20200102165844.133133-1-shakeelb@google.com +Signed-off-by: Greg Kroah-Hartman + +--- + arch/x86/kernel/cpu/resctrl/rdtgroup.c | 6 +++--- + 1 file changed, 3 insertions(+), 3 deletions(-) + +--- a/arch/x86/kernel/cpu/resctrl/rdtgroup.c ++++ b/arch/x86/kernel/cpu/resctrl/rdtgroup.c +@@ -1741,9 +1741,6 @@ static int set_cache_qos_cfg(int level, + struct rdt_domain *d; + int cpu; + +- if (!zalloc_cpumask_var(&cpu_mask, GFP_KERNEL)) +- return -ENOMEM; +- + if (level == RDT_RESOURCE_L3) + update = l3_qos_cfg_update; + else if (level == RDT_RESOURCE_L2) +@@ -1751,6 +1748,9 @@ static int set_cache_qos_cfg(int level, + else + return -EINVAL; + ++ if (!zalloc_cpumask_var(&cpu_mask, GFP_KERNEL)) ++ return -ENOMEM; ++ + r_l = &rdt_resources_all[level]; + list_for_each_entry(d, &r_l->domains, list) { + /* Pick one CPU from each domain instance to update MSR */ -- 2.47.3