--- /dev/null
+From 67f96ff7c8f073648696eab50fd23ded23441067 Mon Sep 17 00:00:00 2001
+From: Marek Szyprowski <m.szyprowski@samsung.com>
+Date: Mon, 16 Dec 2019 14:14:07 +0100
+Subject: clk: samsung: exynos5420: Keep top G3D clocks enabled
+
+From: Marek Szyprowski <m.szyprowski@samsung.com>
+
+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
+...
+[<c05c231c>] (panfrost_gpu_soft_reset) from [<c05c2704>] (panfrost_gpu_init+0x10/0x67c)
+[<c05c2704>] (panfrost_gpu_init) from [<c05c15d0>] (panfrost_device_init+0x158/0x2cc)
+[<c05c15d0>] (panfrost_device_init) from [<c05c0cb0>] (panfrost_probe+0x80/0x178)
+[<c05c0cb0>] (panfrost_probe) from [<c05cfaa0>] (platform_drv_probe+0x48/0x9c)
+[<c05cfaa0>] (platform_drv_probe) from [<c05cd20c>] (really_probe+0x1c4/0x474)
+[<c05cd20c>] (really_probe) from [<c05cd694>] (driver_probe_device+0x78/0x1bc)
+[<c05cd694>] (driver_probe_device) from [<c05cb374>] (bus_for_each_drv+0x74/0xb8)
+[<c05cb374>] (bus_for_each_drv) from [<c05ccfa8>] (__device_attach+0xd4/0x16c)
+[<c05ccfa8>] (__device_attach) from [<c05cc110>] (bus_probe_device+0x88/0x90)
+[<c05cc110>] (bus_probe_device) from [<c05cc634>] (deferred_probe_work_func+0x4c/0xd0)
+[<c05cc634>] (deferred_probe_work_func) from [<c0149df0>] (process_one_work+0x300/0x864)
+[<c0149df0>] (process_one_work) from [<c014a3ac>] (worker_thread+0x58/0x5a0)
+[<c014a3ac>] (worker_thread) from [<c0151174>] (kthread+0x12c/0x160)
+[<c0151174>] (kthread) from [<c01010b4>] (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 <m.szyprowski@samsung.com>
+Link: https://lkml.kernel.org/r/20191216131407.17225-1-m.szyprowski@samsung.com
+Acked-by: Krzysztof Kozlowski <krzk@kernel.org>
+Acked-by: Chanwoo Choi <cw00.choi@samsung.com>
+Acked-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
+Signed-off-by: Stephen Boyd <sboyd@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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 <linux/clk-provider.h>
+ #include <linux/of.h>
+ #include <linux/of_address.h>
++#include <linux/clk.h>
+
+ #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);
+ }
+
--- /dev/null
+From dc8d37ed304eeeea47e65fb9edc1c6c8b0093386 Mon Sep 17 00:00:00 2001
+From: Arnd Bergmann <arnd@arndb.de>
+Date: Tue, 10 Dec 2019 20:56:04 +0100
+Subject: cpu/SMT: Fix x86 link error without CONFIG_SYSFS
+
+From: Arnd Bergmann <arnd@arndb.de>
+
+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 <arnd@arndb.de>
+Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
+Reviewed-by: Jiri Kosina <jkosina@suse.cz>
+Cc: stable@vger.kernel.org
+Link: https://lore.kernel.org/r/20191210195614.786555-1-arnd@arndb.de
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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)
--- /dev/null
+From ea38aa2ea5b0969776f0a47f174ce928a22be803 Mon Sep 17 00:00:00 2001
+From: YueHaibing <yuehaibing@huawei.com>
+Date: Tue, 7 Jan 2020 21:50:14 +0800
+Subject: drm/i915: Add missing include file <linux/math64.h>
+
+From: YueHaibing <yuehaibing@huawei.com>
+
+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 <hulkci@huawei.com>
+Fixes: 7ce5b6850b47 ("drm/i915/selftests: Use mul_u32_u32() for 32b x 32b -> 64b result")
+Signed-off-by: YueHaibing <yuehaibing@huawei.com>
+Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
+Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
+Link: https://patchwork.freedesktop.org/patch/msgid/20200107135014.36472-1-yuehaibing@huawei.com
+(cherry picked from commit 62bf5465b26d1f502430b9c654be7d16bf2e242d)
+Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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 <linux/math64.h>
+ #include <linux/random.h>
+
+ #include "../i915_selftest.h"
--- /dev/null
+From d92b54570d24d017d2630e314b525ed792f5aa6c Mon Sep 17 00:00:00 2001
+From: Arvind Sankar <nivedita@alum.mit.edu>
+Date: Tue, 24 Dec 2019 14:29:07 +0100
+Subject: efi/earlycon: Fix write-combine mapping on x86
+
+From: Arvind Sankar <nivedita@alum.mit.edu>
+
+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 <nivedita@alum.mit.edu>
+Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
+Cc: Hans de Goede <hdegoede@redhat.com>
+Cc: Linus Torvalds <torvalds@linux-foundation.org>
+Cc: Peter Zijlstra <peterz@infradead.org>
+Cc: Thomas Gleixner <tglx@linutronix.de>
+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 <mingo@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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;
--- /dev/null
+From d91f3057263ceb691ef527e71b41a56b17f6c869 Mon Sep 17 00:00:00 2001
+From: Waiman Long <longman@redhat.com>
+Date: Fri, 20 Dec 2019 08:51:28 -0500
+Subject: locking/lockdep: Fix buffer overrun problem in stack_trace[]
+
+From: Waiman Long <longman@redhat.com>
+
+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 <longman@redhat.com>
+Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
+Reviewed-by: Bart Van Assche <bvanassche@acm.org>
+Cc: Linus Torvalds <torvalds@linux-foundation.org>
+Cc: Peter Zijlstra <peterz@infradead.org>
+Cc: Thomas Gleixner <tglx@linutronix.de>
+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 <mingo@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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);
--- /dev/null
+From 39e7234f00bc93613c086ae42d852d5f4147120a Mon Sep 17 00:00:00 2001
+From: Waiman Long <longman@redhat.com>
+Date: Wed, 15 Jan 2020 10:43:36 -0500
+Subject: locking/rwsem: Fix kernel crash when spinning on RWSEM_OWNER_UNKNOWN
+
+From: Waiman Long <longman@redhat.com>
+
+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 <hch@lst.de>
+Signed-off-by: Waiman Long <longman@redhat.com>
+Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
+Tested-by: Christoph Hellwig <hch@lst.de>
+Cc: stable@vger.kernel.org
+Link: https://lkml.kernel.org/r/20200115154336.8679-1-longman@redhat.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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. */
--- /dev/null
+From 5bc6bb603b4d0c8802af75e4932232683ab2d761 Mon Sep 17 00:00:00 2001
+From: Esben Haabendal <esben@geanix.com>
+Date: Fri, 17 Jan 2020 21:05:36 +0100
+Subject: mtd: rawnand: gpmi: Fix suspend/resume problem
+
+From: Esben Haabendal <esben@geanix.com>
+
+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 <esben@geanix.com>
+Acked-by: Han Xu <han.xu@nxp.com>
+Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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;
+ }
+
--- /dev/null
+From d70486668cdf51b14a50425ab45fc18677a167b2 Mon Sep 17 00:00:00 2001
+From: Esben Haabendal <esben@geanix.com>
+Date: Fri, 17 Jan 2020 21:05:37 +0100
+Subject: mtd: rawnand: gpmi: Restore nfc timing setup after suspend/resume
+
+From: Esben Haabendal <esben@geanix.com>
+
+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 <esben@geanix.com>
+Acked-by: Han Xu <han.xu@nxp.com>
+Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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) {
--- /dev/null
+From 440b6d50254bdbd84c2a665c7f53ec69dd741a4f Mon Sep 17 00:00:00 2001
+From: Vignesh Raghavendra <vigneshr@ti.com>
+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 <vigneshr@ti.com>
+
+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 <vigneshr@ti.com>
+Reviewed-by: Tudor Ambarus <tudor.ambarus@microchip.com>
+Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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;
--- /dev/null
+From 55347ec340af401437680fd0e88df6739a967f9f Mon Sep 17 00:00:00 2001
+From: Yuya Fujita <fujita.yuya@fujitsu.com>
+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 <fujita.yuya@fujitsu.com>
+
+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 <fujita.yuya@fujitsu.com>
+Acked-by: Jiri Olsa <jolsa@kernel.org>
+Cc: Peter Zijlstra <peterz@infradead.org>
+Link: http://lore.kernel.org/lkml/OSAPR01MB1588E1C47AC22043175DE1B2E8520@OSAPR01MB1588.jpnprd01.prod.outlook.com
+Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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[];
+
--- /dev/null
+From 0feba17bd7ee3b7e03d141f119049dcc23efa94e Mon Sep 17 00:00:00 2001
+From: Jin Yao <yao.jin@linux.intel.com>
+Date: Fri, 20 Dec 2019 09:37:19 +0800
+Subject: perf report: Fix incorrectly added dimensions as switch perf data file
+
+From: Jin Yao <yao.jin@linux.intel.com>
+
+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 <yao.jin@linux.intel.com>
+Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com>
+Acked-by: Jiri Olsa <jolsa@redhat.com>
+Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
+Cc: Andi Kleen <ak@linux.intel.com>
+Cc: Feng Tang <feng.tang@intel.com>
+Cc: Jin Yao <yao.jin@intel.com>
+Cc: Kan Liang <kan.liang@linux.intel.com>
+Cc: Peter Zijlstra <peterz@infradead.org>
+Link: http://lore.kernel.org/lkml/20191220013722.20592-1-yao.jin@linux.intel.com
+Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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;
--- /dev/null
+From fa694ae532836bd2f4cd659e9b4032abaf9fa9e5 Mon Sep 17 00:00:00 2001
+From: Kan Liang <kan.liang@linux.intel.com>
+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 <kan.liang@linux.intel.com>
+
+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 <like.xu@linux.intel.com>
+Signed-off-by: Kan Liang <kan.liang@linux.intel.com>
+Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
+Signed-off-by: Ingo Molnar <mingo@kernel.org>
+Tested-by: Like Xu <like.xu@linux.intel.com>
+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 <gregkh@linuxfoundation.org>
+
+---
+ 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 = {
--- /dev/null
+From 6b3ad6649a4c75504edeba242d3fd36b3096a57f Mon Sep 17 00:00:00 2001
+From: Christian Brauner <christian.brauner@ubuntu.com>
+Date: Wed, 15 Jan 2020 14:42:34 +0100
+Subject: ptrace: reintroduce usage of subjective credentials in ptrace_has_cap()
+
+From: Christian Brauner <christian.brauner@ubuntu.com>
+
+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 <oleg@redhat.com>
+Cc: Eric Paris <eparis@redhat.com>
+Cc: stable@vger.kernel.org
+Reviewed-by: Kees Cook <keescook@chromium.org>
+Reviewed-by: Serge Hallyn <serge@hallyn.com>
+Reviewed-by: Jann Horn <jannh@google.com>
+Fixes: 69f594a38967 ("ptrace: do not audit capability check when outputing /proc/pid/stat")
+Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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);
--- /dev/null
+From 40260b01d029ba374637838213af500e03305326 Mon Sep 17 00:00:00 2001
+From: Philipp Rudo <prudo@linux.ibm.com>
+Date: Wed, 18 Dec 2019 11:24:43 +0100
+Subject: s390/setup: Fix secure ipl message
+
+From: Philipp Rudo <prudo@linux.ibm.com>
+
+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 <prudo@linux.ibm.com>
+Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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");
--- /dev/null
+From 94dd3bada53ee77b80d0aeee5571eeb83654d156 Mon Sep 17 00:00:00 2001
+From: Harald Freudenberger <freude@linux.ibm.com>
+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 <freude@linux.ibm.com>
+
+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 <stable@vger.kernel.org>
+Signed-off-by: Harald Freudenberger <freude@linux.ibm.com>
+Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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;
--- /dev/null
+From 7b571c19d4c0b78d27dd3bf1f3c42e4032390af6 Mon Sep 17 00:00:00 2001
+From: Long Li <longli@microsoft.com>
+Date: Mon, 13 Jan 2020 16:08:36 -0800
+Subject: scsi: storvsc: Correctly set number of hardware queues for IDE disk
+
+From: Long Li <longli@microsoft.com>
+
+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 <ming.lei@redhat.com>
+Signed-off-by: Long Li <longli@microsoft.com>
+Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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.
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
--- /dev/null
+From 9c06ac4c83df6d6fbdbf7488fbad822b4002ba19 Mon Sep 17 00:00:00 2001
+From: Keiya Nobuta <nobuta.keiya@fujitsu.com>
+Date: Thu, 9 Jan 2020 14:14:48 +0900
+Subject: usb: core: hub: Improved device recognition on remote wakeup
+
+From: Keiya Nobuta <nobuta.keiya@fujitsu.com>
+
+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 <nobuta.keiya@fujitsu.com>
+Cc: stable <stable@vger.kernel.org>
+Acked-by: Alan Stern <stern@rowland.harvard.edu>
+Link: https://lore.kernel.org/r/20200109051448.28150-1-nobuta.keiya@fujitsu.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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);
--- /dev/null
+From a006483b2f97af685f0e60f3a547c9ad4c9b9e94 Mon Sep 17 00:00:00 2001
+From: Tom Lendacky <thomas.lendacky@amd.com>
+Date: Wed, 15 Jan 2020 16:05:16 -0600
+Subject: x86/CPU/AMD: Ensure clearing of SME/SEV features is maintained
+
+From: Tom Lendacky <thomas.lendacky@amd.com>
+
+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 <thomas.lendacky@amd.com>
+Signed-off-by: Borislav Petkov <bp@suse.de>
+Cc: <stable@vger.kernel.org> # 4.16.x-
+Link: https://lkml.kernel.org/r/226de90a703c3c0be5a49565047905ac4e94e8f3.1579125915.git.thomas.lendacky@amd.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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);
+ }
+ }
+
--- /dev/null
+From 4911ee401b7ceff8f38e0ac597cbf503d71e690c Mon Sep 17 00:00:00 2001
+From: Ard Biesheuvel <ardb@kernel.org>
+Date: Tue, 24 Dec 2019 14:29:09 +0100
+Subject: x86/efistub: Disable paging at mixed mode entry
+
+From: Ard Biesheuvel <ardb@kernel.org>
+
+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 <ardb@kernel.org>
+Cc: <stable@vger.kernel.org>
+Cc: Arvind Sankar <nivedita@alum.mit.edu>
+Cc: Hans de Goede <hdegoede@redhat.com>
+Cc: Linus Torvalds <torvalds@linux-foundation.org>
+Cc: Peter Zijlstra <peterz@infradead.org>
+Cc: Thomas Gleixner <tglx@linutronix.de>
+Cc: linux-efi@vger.kernel.org
+Link: https://lkml.kernel.org/r/20191224132909.102540-4-ardb@kernel.org
+Signed-off-by: Ingo Molnar <mingo@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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
--- /dev/null
+From e278af89f1ba0a9ef20947db6afc2c9afa37e85b Mon Sep 17 00:00:00 2001
+From: Qian Cai <cai@lca.pw>
+Date: Tue, 10 Dec 2019 22:30:42 -0500
+Subject: x86/resctrl: Fix an imbalance in domain_remove_cpu()
+
+From: Qian Cai <cai@lca.pw>
+
+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 <cai@lca.pw>
+Signed-off-by: Borislav Petkov <bp@suse.de>
+Acked-by: Reinette Chatre <reinette.chatre@intel.com>
+Cc: Fenghua Yu <fenghua.yu@intel.com>
+Cc: "H. Peter Anvin" <hpa@zytor.com>
+Cc: Ingo Molnar <mingo@redhat.com>
+Cc: john.stultz@linaro.org
+Cc: sboyd@kernel.org
+Cc: <stable@vger.kernel.org>
+Cc: Thomas Gleixner <tglx@linutronix.de>
+Cc: tj@kernel.org
+Cc: Tony Luck <tony.luck@intel.com>
+Cc: Vikas Shivappa <vikas.shivappa@linux.intel.com>
+Cc: x86-ml <x86@kernel.org>
+Link: https://lkml.kernel.org/r/20191211033042.2188-1-cai@lca.pw
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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)) {
+ /*
--- /dev/null
+From ab6a2114433a3b5b555983dcb9b752a85255f04b Mon Sep 17 00:00:00 2001
+From: Shakeel Butt <shakeelb@google.com>
+Date: Thu, 2 Jan 2020 08:58:44 -0800
+Subject: x86/resctrl: Fix potential memory leak
+
+From: Shakeel Butt <shakeelb@google.com>
+
+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 <shakeelb@google.com>
+Signed-off-by: Borislav Petkov <bp@suse.de>
+Cc: Fenghua Yu <fenghua.yu@intel.com>
+Cc: "H. Peter Anvin" <hpa@zytor.com>
+Cc: Ingo Molnar <mingo@redhat.com>
+Cc: Reinette Chatre <reinette.chatre@intel.com>
+Cc: Thomas Gleixner <tglx@linutronix.de>
+Cc: x86-ml <x86@kernel.org>
+Link: https://lkml.kernel.org/r/20200102165844.133133-1-shakeelb@google.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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 */
projects / thirdparty / kernel / stable-queue.git / commitdiff
