--- /dev/null
+From 4a132f60808ae3a751e107a373f8572012352d3c Mon Sep 17 00:00:00 2001
+From: Jagan Teki <jagan@amarulasolutions.com>
+Date: Mon, 30 Dec 2019 17:30:19 +0530
+Subject: ARM: dts: imx6q-icore-mipi: Use 1.5 version of i.Core MX6DL
+
+From: Jagan Teki <jagan@amarulasolutions.com>
+
+commit 4a132f60808ae3a751e107a373f8572012352d3c upstream.
+
+The EDIMM STARTER KIT i.Core 1.5 MIPI Evaluation is based on
+the 1.5 version of the i.Core MX6 cpu module. The 1.5 version
+differs from the original one for a few details, including the
+ethernet PHY interface clock provider.
+
+With this commit, the ethernet interface works properly:
+SMSC LAN8710/LAN8720 2188000.ethernet-1:00: attached PHY driver
+
+While before using the 1.5 version, ethernet failed to startup
+do to un-clocked PHY interface:
+fec 2188000.ethernet eth0: could not attach to PHY
+
+Similar fix has merged for i.Core MX6Q but missed to update for DL.
+
+Fixes: a8039f2dd089 ("ARM: dts: imx6dl: Add Engicam i.CoreM6 1.5 Quad/Dual MIPI starter kit support")
+Cc: Jacopo Mondi <jacopo@jmondi.org>
+Signed-off-by: Michael Trimarchi <michael@amarulasolutions.com>
+Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
+Signed-off-by: Shawn Guo <shawnguo@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/arm/boot/dts/imx6dl-icore-mipi.dts | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/arch/arm/boot/dts/imx6dl-icore-mipi.dts
++++ b/arch/arm/boot/dts/imx6dl-icore-mipi.dts
+@@ -8,7 +8,7 @@
+ /dts-v1/;
+
+ #include "imx6dl.dtsi"
+-#include "imx6qdl-icore.dtsi"
++#include "imx6qdl-icore-1.5.dtsi"
+
+ / {
+ model = "Engicam i.CoreM6 DualLite/Solo MIPI Starter Kit";
--- /dev/null
+From 4b0b97e651ecf29f20248420b52b6864fbd40bc2 Mon Sep 17 00:00:00 2001
+From: Marcel Ziswiler <marcel.ziswiler@toradex.com>
+Date: Wed, 8 Jan 2020 17:12:31 +0100
+Subject: ARM: dts: imx7: Fix Toradex Colibri iMX7S 256MB NAND flash support
+
+From: Marcel Ziswiler <marcel.ziswiler@toradex.com>
+
+commit 4b0b97e651ecf29f20248420b52b6864fbd40bc2 upstream.
+
+Turns out when introducing the eMMC version the gpmi node required for
+NAND flash support got enabled exclusively on Colibri iMX7D 512MB.
+
+Fixes: f928a4a377e4 ("ARM: dts: imx7: add Toradex Colibri iMX7D 1GB (eMMC) support")
+Signed-off-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
+Signed-off-by: Shawn Guo <shawnguo@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/arm/boot/dts/imx7s-colibri.dtsi | 4 ++++
+ 1 file changed, 4 insertions(+)
+
+--- a/arch/arm/boot/dts/imx7s-colibri.dtsi
++++ b/arch/arm/boot/dts/imx7s-colibri.dtsi
+@@ -49,3 +49,7 @@
+ reg = <0x80000000 0x10000000>;
+ };
+ };
++
++&gpmi {
++ status = "okay";
++};
--- /dev/null
+From 423a716cd7be16fb08690760691befe3be97d3fc Mon Sep 17 00:00:00 2001
+From: Josef Bacik <josef@toxicpanda.com>
+Date: Wed, 18 Dec 2019 17:20:29 -0500
+Subject: btrfs: do not delete mismatched root refs
+
+From: Josef Bacik <josef@toxicpanda.com>
+
+commit 423a716cd7be16fb08690760691befe3be97d3fc upstream.
+
+btrfs_del_root_ref() will simply WARN_ON() if the ref doesn't match in
+any way, and then continue to delete the reference. This shouldn't
+happen, we have these values because there's more to the reference than
+the original root and the sub root. If any of these checks fail, return
+-ENOENT.
+
+CC: stable@vger.kernel.org # 4.4+
+Signed-off-by: Josef Bacik <josef@toxicpanda.com>
+Reviewed-by: David Sterba <dsterba@suse.com>
+Signed-off-by: David Sterba <dsterba@suse.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/btrfs/root-tree.c | 10 ++++++----
+ 1 file changed, 6 insertions(+), 4 deletions(-)
+
+--- a/fs/btrfs/root-tree.c
++++ b/fs/btrfs/root-tree.c
+@@ -370,11 +370,13 @@ again:
+ leaf = path->nodes[0];
+ ref = btrfs_item_ptr(leaf, path->slots[0],
+ struct btrfs_root_ref);
+-
+- WARN_ON(btrfs_root_ref_dirid(leaf, ref) != dirid);
+- WARN_ON(btrfs_root_ref_name_len(leaf, ref) != name_len);
+ ptr = (unsigned long)(ref + 1);
+- WARN_ON(memcmp_extent_buffer(leaf, name, ptr, name_len));
++ if ((btrfs_root_ref_dirid(leaf, ref) != dirid) ||
++ (btrfs_root_ref_name_len(leaf, ref) != name_len) ||
++ memcmp_extent_buffer(leaf, name, ptr, name_len)) {
++ err = -ENOENT;
++ goto out;
++ }
+ *sequence = btrfs_root_ref_sequence(leaf, ref);
+
+ ret = btrfs_del_item(trans, tree_root, path);
--- /dev/null
+From d49d3287e74ffe55ae7430d1e795e5f9bf7359ea Mon Sep 17 00:00:00 2001
+From: Josef Bacik <josef@toxicpanda.com>
+Date: Wed, 18 Dec 2019 17:20:28 -0500
+Subject: btrfs: fix invalid removal of root ref
+
+From: Josef Bacik <josef@toxicpanda.com>
+
+commit d49d3287e74ffe55ae7430d1e795e5f9bf7359ea upstream.
+
+If we have the following sequence of events
+
+ btrfs sub create A
+ btrfs sub create A/B
+ btrfs sub snap A C
+ mkdir C/foo
+ mv A/B C/foo
+ rm -rf *
+
+We will end up with a transaction abort.
+
+The reason for this is because we create a root ref for B pointing to A.
+When we create a snapshot of C we still have B in our tree, but because
+the root ref points to A and not C we will make it appear to be empty.
+
+The problem happens when we move B into C. This removes the root ref
+for B pointing to A and adds a ref of B pointing to C. When we rmdir C
+we'll see that we have a ref to our root and remove the root ref,
+despite not actually matching our reference name.
+
+Now btrfs_del_root_ref() allowing this to work is a bug as well, however
+we know that this inode does not actually point to a root ref in the
+first place, so we shouldn't be calling btrfs_del_root_ref() in the
+first place and instead simply look up our dir index for this item and
+do the rest of the removal.
+
+CC: stable@vger.kernel.org # 4.4+
+Signed-off-by: Josef Bacik <josef@toxicpanda.com>
+Reviewed-by: David Sterba <dsterba@suse.com>
+Signed-off-by: David Sterba <dsterba@suse.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/btrfs/inode.c | 27 +++++++++++++++++++--------
+ 1 file changed, 19 insertions(+), 8 deletions(-)
+
+--- a/fs/btrfs/inode.c
++++ b/fs/btrfs/inode.c
+@@ -4156,13 +4156,16 @@ static int btrfs_unlink_subvol(struct bt
+ }
+ btrfs_release_path(path);
+
+- ret = btrfs_del_root_ref(trans, objectid, root->root_key.objectid,
+- dir_ino, &index, name, name_len);
+- if (ret < 0) {
+- if (ret != -ENOENT) {
+- btrfs_abort_transaction(trans, ret);
+- goto out;
+- }
++ /*
++ * This is a placeholder inode for a subvolume we didn't have a
++ * reference to at the time of the snapshot creation. In the meantime
++ * we could have renamed the real subvol link into our snapshot, so
++ * depending on btrfs_del_root_ref to return -ENOENT here is incorret.
++ * Instead simply lookup the dir_index_item for this entry so we can
++ * remove it. Otherwise we know we have a ref to the root and we can
++ * call btrfs_del_root_ref, and it _shouldn't_ fail.
++ */
++ if (btrfs_ino(inode) == BTRFS_EMPTY_SUBVOL_DIR_OBJECTID) {
+ di = btrfs_search_dir_index_item(root, path, dir_ino,
+ name, name_len);
+ if (IS_ERR_OR_NULL(di)) {
+@@ -4177,8 +4180,16 @@ static int btrfs_unlink_subvol(struct bt
+ leaf = path->nodes[0];
+ btrfs_item_key_to_cpu(leaf, &key, path->slots[0]);
+ index = key.offset;
++ btrfs_release_path(path);
++ } else {
++ ret = btrfs_del_root_ref(trans, objectid,
++ root->root_key.objectid, dir_ino,
++ &index, name, name_len);
++ if (ret) {
++ btrfs_abort_transaction(trans, ret);
++ goto out;
++ }
+ }
+- btrfs_release_path(path);
+
+ ret = btrfs_delete_delayed_dir_index(trans, BTRFS_I(dir), index);
+ if (ret) {
--- /dev/null
+From 26ef8493e1ab771cb01d27defca2fa1315dc3980 Mon Sep 17 00:00:00 2001
+From: Johannes Thumshirn <johannes.thumshirn@wdc.com>
+Date: Wed, 8 Jan 2020 21:07:32 +0900
+Subject: btrfs: fix memory leak in qgroup accounting
+
+From: Johannes Thumshirn <johannes.thumshirn@wdc.com>
+
+commit 26ef8493e1ab771cb01d27defca2fa1315dc3980 upstream.
+
+When running xfstests on the current btrfs I get the following splat from
+kmemleak:
+
+unreferenced object 0xffff88821b2404e0 (size 32):
+ comm "kworker/u4:7", pid 26663, jiffies 4295283698 (age 8.776s)
+ hex dump (first 32 bytes):
+ 01 00 00 00 00 00 00 00 10 ff fd 26 82 88 ff ff ...........&....
+ 10 ff fd 26 82 88 ff ff 20 ff fd 26 82 88 ff ff ...&.... ..&....
+ backtrace:
+ [<00000000f94fd43f>] ulist_alloc+0x25/0x60 [btrfs]
+ [<00000000fd023d99>] btrfs_find_all_roots_safe+0x41/0x100 [btrfs]
+ [<000000008f17bd32>] btrfs_find_all_roots+0x52/0x70 [btrfs]
+ [<00000000b7660afb>] btrfs_qgroup_rescan_worker+0x343/0x680 [btrfs]
+ [<0000000058e66778>] btrfs_work_helper+0xac/0x1e0 [btrfs]
+ [<00000000f0188930>] process_one_work+0x1cf/0x350
+ [<00000000af5f2f8e>] worker_thread+0x28/0x3c0
+ [<00000000b55a1add>] kthread+0x109/0x120
+ [<00000000f88cbd17>] ret_from_fork+0x35/0x40
+
+This corresponds to:
+
+ (gdb) l *(btrfs_find_all_roots_safe+0x41)
+ 0x8d7e1 is in btrfs_find_all_roots_safe (fs/btrfs/backref.c:1413).
+ 1408
+ 1409 tmp = ulist_alloc(GFP_NOFS);
+ 1410 if (!tmp)
+ 1411 return -ENOMEM;
+ 1412 *roots = ulist_alloc(GFP_NOFS);
+ 1413 if (!*roots) {
+ 1414 ulist_free(tmp);
+ 1415 return -ENOMEM;
+ 1416 }
+ 1417
+
+Following the lifetime of the allocated 'roots' ulist, it gets freed
+again in btrfs_qgroup_account_extent().
+
+But this does not happen if the function is called with the
+'BTRFS_FS_QUOTA_ENABLED' flag cleared, then btrfs_qgroup_account_extent()
+does a short leave and directly returns.
+
+Instead of directly returning we should jump to the 'out_free' in order to
+free all resources as expected.
+
+CC: stable@vger.kernel.org # 4.14+
+Reviewed-by: Qu Wenruo <wqu@suse.com>
+Signed-off-by: Johannes Thumshirn <johannes.thumshirn@wdc.com>
+[ add comment ]
+Signed-off-by: David Sterba <dsterba@suse.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/btrfs/qgroup.c | 6 +++++-
+ 1 file changed, 5 insertions(+), 1 deletion(-)
+
+--- a/fs/btrfs/qgroup.c
++++ b/fs/btrfs/qgroup.c
+@@ -2055,8 +2055,12 @@ int btrfs_qgroup_account_extent(struct b
+ u64 nr_old_roots = 0;
+ int ret = 0;
+
++ /*
++ * If quotas get disabled meanwhile, the resouces need to be freed and
++ * we can't just exit here.
++ */
+ if (!test_bit(BTRFS_FS_QUOTA_ENABLED, &fs_info->flags))
+- return 0;
++ goto out_free;
+
+ if (new_roots) {
+ if (!maybe_fs_roots(new_roots))
--- /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 2fe20210fc5f5e62644678b8f927c49f2c6f42a7 Mon Sep 17 00:00:00 2001
+From: Adrian Huang <ahuang12@lenovo.com>
+Date: Mon, 13 Jan 2020 16:29:32 -0800
+Subject: mm: memcg/slab: call flush_memcg_workqueue() only if memcg workqueue is valid
+
+From: Adrian Huang <ahuang12@lenovo.com>
+
+commit 2fe20210fc5f5e62644678b8f927c49f2c6f42a7 upstream.
+
+When booting with amd_iommu=off, the following WARNING message
+appears:
+
+ AMD-Vi: AMD IOMMU disabled on kernel command-line
+ ------------[ cut here ]------------
+ WARNING: CPU: 0 PID: 0 at kernel/workqueue.c:2772 flush_workqueue+0x42e/0x450
+ Modules linked in:
+ CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.5.0-rc3-amd-iommu #6
+ Hardware name: Lenovo ThinkSystem SR655-2S/7D2WRCZ000, BIOS D8E101L-1.00 12/05/2019
+ RIP: 0010:flush_workqueue+0x42e/0x450
+ Code: ff 0f 0b e9 7a fd ff ff 4d 89 ef e9 33 fe ff ff 0f 0b e9 7f fd ff ff 0f 0b e9 bc fd ff ff 0f 0b e9 a8 fd ff ff e8 52 2c fe ff <0f> 0b 31 d2 48 c7 c6 e0 88 c5 95 48 c7 c7 d8 ad f0 95 e8 19 f5 04
+ Call Trace:
+ kmem_cache_destroy+0x69/0x260
+ iommu_go_to_state+0x40c/0x5ab
+ amd_iommu_prepare+0x16/0x2a
+ irq_remapping_prepare+0x36/0x5f
+ enable_IR_x2apic+0x21/0x172
+ default_setup_apic_routing+0x12/0x6f
+ apic_intr_mode_init+0x1a1/0x1f1
+ x86_late_time_init+0x17/0x1c
+ start_kernel+0x480/0x53f
+ secondary_startup_64+0xb6/0xc0
+ ---[ end trace 30894107c3749449 ]---
+ x2apic: IRQ remapping doesn't support X2APIC mode
+ x2apic disabled
+
+The warning is caused by the calling of 'kmem_cache_destroy()'
+in free_iommu_resources(). Here is the call path:
+
+ free_iommu_resources
+ kmem_cache_destroy
+ flush_memcg_workqueue
+ flush_workqueue
+
+The root cause is that the IOMMU subsystem runs before the workqueue
+subsystem, which the variable 'wq_online' is still 'false'. This leads
+to the statement 'if (WARN_ON(!wq_online))' in flush_workqueue() is
+'true'.
+
+Since the variable 'memcg_kmem_cache_wq' is not allocated during the
+time, it is unnecessary to call flush_memcg_workqueue(). This prevents
+the WARNING message triggered by flush_workqueue().
+
+Link: http://lkml.kernel.org/r/20200103085503.1665-1-ahuang12@lenovo.com
+Fixes: 92ee383f6daab ("mm: fix race between kmem_cache destroy, create and deactivate")
+Signed-off-by: Adrian Huang <ahuang12@lenovo.com>
+Reported-by: Xiaochun Lee <lixc17@lenovo.com>
+Reviewed-by: Shakeel Butt <shakeelb@google.com>
+Cc: Joerg Roedel <jroedel@suse.de>
+Cc: Christoph Lameter <cl@linux.com>
+Cc: Pekka Enberg <penberg@kernel.org>
+Cc: David Rientjes <rientjes@google.com>
+Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
+Cc: Michal Hocko <mhocko@kernel.org>
+Cc: Johannes Weiner <hannes@cmpxchg.org>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ mm/slab_common.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/mm/slab_common.c
++++ b/mm/slab_common.c
+@@ -850,7 +850,8 @@ static void flush_memcg_workqueue(struct
+ * deactivates the memcg kmem_caches through workqueue. Make sure all
+ * previous workitems on workqueue are processed.
+ */
+- flush_workqueue(memcg_kmem_cache_wq);
++ if (likely(memcg_kmem_cache_wq))
++ flush_workqueue(memcg_kmem_cache_wq);
+ }
+ #else
+ static inline int shutdown_memcg_caches(struct kmem_cache *s)
--- /dev/null
+From 6d9e8c651dd979aa666bee15f086745f3ea9c4b3 Mon Sep 17 00:00:00 2001
+From: Wen Yang <wenyang@linux.alibaba.com>
+Date: Mon, 13 Jan 2020 16:29:23 -0800
+Subject: mm/page-writeback.c: avoid potential division by zero in wb_min_max_ratio()
+
+From: Wen Yang <wenyang@linux.alibaba.com>
+
+commit 6d9e8c651dd979aa666bee15f086745f3ea9c4b3 upstream.
+
+Patch series "use div64_ul() instead of div_u64() if the divisor is
+unsigned long".
+
+We were first inspired by commit b0ab99e7736a ("sched: Fix possible divide
+by zero in avg_atom () calculation"), then refer to the recently analyzed
+mm code, we found this suspicious place.
+
+ 201 if (min) {
+ 202 min *= this_bw;
+ 203 do_div(min, tot_bw);
+ 204 }
+
+And we also disassembled and confirmed it:
+
+ /usr/src/debug/kernel-4.9.168-016.ali3000/linux-4.9.168-016.ali3000.alios7.x86_64/mm/page-writeback.c: 201
+ 0xffffffff811c37da <__wb_calc_thresh+234>: xor %r10d,%r10d
+ 0xffffffff811c37dd <__wb_calc_thresh+237>: test %rax,%rax
+ 0xffffffff811c37e0 <__wb_calc_thresh+240>: je 0xffffffff811c3800 <__wb_calc_thresh+272>
+ /usr/src/debug/kernel-4.9.168-016.ali3000/linux-4.9.168-016.ali3000.alios7.x86_64/mm/page-writeback.c: 202
+ 0xffffffff811c37e2 <__wb_calc_thresh+242>: imul %r8,%rax
+ /usr/src/debug/kernel-4.9.168-016.ali3000/linux-4.9.168-016.ali3000.alios7.x86_64/mm/page-writeback.c: 203
+ 0xffffffff811c37e6 <__wb_calc_thresh+246>: mov %r9d,%r10d ---> truncates it to 32 bits here
+ 0xffffffff811c37e9 <__wb_calc_thresh+249>: xor %edx,%edx
+ 0xffffffff811c37eb <__wb_calc_thresh+251>: div %r10
+ 0xffffffff811c37ee <__wb_calc_thresh+254>: imul %rbx,%rax
+ 0xffffffff811c37f2 <__wb_calc_thresh+258>: shr $0x2,%rax
+ 0xffffffff811c37f6 <__wb_calc_thresh+262>: mul %rcx
+ 0xffffffff811c37f9 <__wb_calc_thresh+265>: shr $0x2,%rdx
+ 0xffffffff811c37fd <__wb_calc_thresh+269>: mov %rdx,%r10
+
+This series uses div64_ul() instead of div_u64() if the divisor is
+unsigned long, to avoid truncation to 32-bit on 64-bit platforms.
+
+This patch (of 3):
+
+The variables 'min' and 'max' are unsigned long and do_div truncates
+them to 32 bits, which means it can test non-zero and be truncated to
+zero for division. Fix this issue by using div64_ul() instead.
+
+Link: http://lkml.kernel.org/r/20200102081442.8273-2-wenyang@linux.alibaba.com
+Fixes: 693108a8a667 ("writeback: make bdi->min/max_ratio handling cgroup writeback aware")
+Signed-off-by: Wen Yang <wenyang@linux.alibaba.com>
+Reviewed-by: Andrew Morton <akpm@linux-foundation.org>
+Cc: Qian Cai <cai@lca.pw>
+Cc: Tejun Heo <tj@kernel.org>
+Cc: Jens Axboe <axboe@kernel.dk>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ mm/page-writeback.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/mm/page-writeback.c
++++ b/mm/page-writeback.c
+@@ -200,11 +200,11 @@ static void wb_min_max_ratio(struct bdi_
+ if (this_bw < tot_bw) {
+ if (min) {
+ min *= this_bw;
+- do_div(min, tot_bw);
++ min = div64_ul(min, tot_bw);
+ }
+ if (max < 100) {
+ max *= this_bw;
+- do_div(max, tot_bw);
++ max = div64_ul(max, tot_bw);
+ }
+ }
+
--- /dev/null
+From 991589974d9c9ecb24ee3799ec8c415c730598a2 Mon Sep 17 00:00:00 2001
+From: "Kirill A. Shutemov" <kirill@shutemov.name>
+Date: Mon, 13 Jan 2020 16:29:13 -0800
+Subject: mm/shmem.c: thp, shmem: fix conflict of above-47bit hint address and PMD alignment
+
+From: Kirill A. Shutemov <kirill@shutemov.name>
+
+commit 991589974d9c9ecb24ee3799ec8c415c730598a2 upstream.
+
+Shmem/tmpfs tries to provide THP-friendly mappings if huge pages are
+enabled. But it doesn't work well with above-47bit hint address.
+
+Normally, the kernel doesn't create userspace mappings above 47-bit,
+even if the machine allows this (such as with 5-level paging on x86-64).
+Not all user space is ready to handle wide addresses. It's known that
+at least some JIT compilers use higher bits in pointers to encode their
+information.
+
+Userspace can ask for allocation from full address space by specifying
+hint address (with or without MAP_FIXED) above 47-bits. If the
+application doesn't need a particular address, but wants to allocate
+from whole address space it can specify -1 as a hint address.
+
+Unfortunately, this trick breaks THP alignment in shmem/tmp:
+shmem_get_unmapped_area() would not try to allocate PMD-aligned area if
+*any* hint address specified.
+
+This can be fixed by requesting the aligned area if the we failed to
+allocated at user-specified hint address. The request with inflated
+length will also take the user-specified hint address. This way we will
+not lose an allocation request from the full address space.
+
+[kirill@shutemov.name: fold in a fixup]
+ Link: http://lkml.kernel.org/r/20191223231309.t6bh5hkbmokihpfu@box
+Link: http://lkml.kernel.org/r/20191220142548.7118-3-kirill.shutemov@linux.intel.com
+Fixes: b569bab78d8d ("x86/mm: Prepare to expose larger address space to userspace")
+Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
+Cc: "Willhalm, Thomas" <thomas.willhalm@intel.com>
+Cc: Dan Williams <dan.j.williams@intel.com>
+Cc: "Bruggeman, Otto G" <otto.g.bruggeman@intel.com>
+Cc: "Aneesh Kumar K . V" <aneesh.kumar@linux.vnet.ibm.com>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ mm/shmem.c | 7 ++++---
+ 1 file changed, 4 insertions(+), 3 deletions(-)
+
+--- a/mm/shmem.c
++++ b/mm/shmem.c
+@@ -2072,9 +2072,10 @@ unsigned long shmem_get_unmapped_area(st
+ /*
+ * Our priority is to support MAP_SHARED mapped hugely;
+ * and support MAP_PRIVATE mapped hugely too, until it is COWed.
+- * But if caller specified an address hint, respect that as before.
++ * But if caller specified an address hint and we allocated area there
++ * successfully, respect that as before.
+ */
+- if (uaddr)
++ if (uaddr == addr)
+ return addr;
+
+ if (shmem_huge != SHMEM_HUGE_FORCE) {
+@@ -2108,7 +2109,7 @@ unsigned long shmem_get_unmapped_area(st
+ if (inflated_len < len)
+ return addr;
+
+- inflated_addr = get_area(NULL, 0, inflated_len, 0, flags);
++ inflated_addr = get_area(NULL, uaddr, inflated_len, 0, flags);
+ if (IS_ERR_VALUE(inflated_addr))
+ return addr;
+ if (inflated_addr & ~PAGE_MASK)
--- /dev/null
+From 8605131747e7e1fd8f6c9f97a00287aae2b2c640 Mon Sep 17 00:00:00 2001
+From: Jose Abreu <Jose.Abreu@synopsys.com>
+Date: Wed, 18 Dec 2019 11:17:41 +0100
+Subject: net: stmmac: 16KB buffer must be 16 byte aligned
+
+From: Jose Abreu <Jose.Abreu@synopsys.com>
+
+commit 8605131747e7e1fd8f6c9f97a00287aae2b2c640 upstream.
+
+The 16KB RX Buffer must also be 16 byte aligned. Fix it.
+
+Fixes: 7ac6653a085b ("stmmac: Move the STMicroelectronics driver")
+Signed-off-by: Jose Abreu <Jose.Abreu@synopsys.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/net/ethernet/stmicro/stmmac/common.h | 5 ++---
+ 1 file changed, 2 insertions(+), 3 deletions(-)
+
+--- a/drivers/net/ethernet/stmicro/stmmac/common.h
++++ b/drivers/net/ethernet/stmicro/stmmac/common.h
+@@ -363,9 +363,8 @@ struct dma_features {
+ unsigned int frpes;
+ };
+
+-/* GMAC TX FIFO is 8K, Rx FIFO is 16K */
+-#define BUF_SIZE_16KiB 16384
+-/* RX Buffer size must be < 8191 and multiple of 4/8/16 bytes */
++/* RX Buffer size must be multiple of 4/8/16 bytes */
++#define BUF_SIZE_16KiB 16368
+ #define BUF_SIZE_8KiB 8188
+ #define BUF_SIZE_4KiB 4096
+ #define BUF_SIZE_2KiB 2048
--- /dev/null
+From b2f3a481c4cd62f78391b836b64c0a6e72b503d2 Mon Sep 17 00:00:00 2001
+From: Jose Abreu <Jose.Abreu@synopsys.com>
+Date: Wed, 18 Dec 2019 11:17:42 +0100
+Subject: net: stmmac: Enable 16KB buffer size
+
+From: Jose Abreu <Jose.Abreu@synopsys.com>
+
+commit b2f3a481c4cd62f78391b836b64c0a6e72b503d2 upstream.
+
+XGMAC supports maximum MTU that can go to 16KB. Lets add this check in
+the calculation of RX buffer size.
+
+Fixes: 7ac6653a085b ("stmmac: Move the STMicroelectronics driver")
+Signed-off-by: Jose Abreu <Jose.Abreu@synopsys.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 4 +++-
+ 1 file changed, 3 insertions(+), 1 deletion(-)
+
+--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
++++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+@@ -1082,7 +1082,9 @@ static int stmmac_set_bfsize(int mtu, in
+ {
+ int ret = bufsize;
+
+- if (mtu >= BUF_SIZE_4KiB)
++ if (mtu >= BUF_SIZE_8KiB)
++ ret = BUF_SIZE_16KiB;
++ else if (mtu >= BUF_SIZE_4KiB)
+ ret = BUF_SIZE_8KiB;
+ else if (mtu >= BUF_SIZE_2KiB)
+ ret = BUF_SIZE_4KiB;
--- /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
+@@ -324,10 +324,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
+@@ -961,6 +961,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"
+ const char report_callchain_help[] = "Display call graph (stack chain/backtrace):\n\n"
+@@ -1292,7 +1293,8 @@ repeat:
+ else
+ use_browser = 0;
+
+- 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)
+@@ -1390,6 +1392,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 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
+@@ -258,12 +258,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. */
+@@ -315,7 +320,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;
+@@ -334,7 +339,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);
fix-built-in-early-load-intel-microcode-alignment.patch
block-fix-an-integer-overflow-in-logical-block-size.patch
arm-dts-am571x-idk-fix-gpios-property-to-have-the-correct-gpio-number.patch
+ptrace-reintroduce-usage-of-subjective-credentials-in-ptrace_has_cap.patch
+usb-core-hub-improved-device-recognition-on-remote-wakeup.patch
+x86-resctrl-fix-an-imbalance-in-domain_remove_cpu.patch
+x86-cpu-amd-ensure-clearing-of-sme-sev-features-is-maintained.patch
+x86-efistub-disable-paging-at-mixed-mode-entry.patch
+drm-i915-add-missing-include-file-linux-math64.h.patch
+x86-resctrl-fix-potential-memory-leak.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
+mm-shmem.c-thp-shmem-fix-conflict-of-above-47bit-hint-address-and-pmd-alignment.patch
+mm-memcg-slab-call-flush_memcg_workqueue-only-if-memcg-workqueue-is-valid.patch
+btrfs-fix-invalid-removal-of-root-ref.patch
+btrfs-do-not-delete-mismatched-root-refs.patch
+btrfs-fix-memory-leak-in-qgroup-accounting.patch
+mm-page-writeback.c-avoid-potential-division-by-zero-in-wb_min_max_ratio.patch
+arm-dts-imx6q-icore-mipi-use-1.5-version-of-i.core-mx6dl.patch
+arm-dts-imx7-fix-toradex-colibri-imx7s-256mb-nand-flash-support.patch
+net-stmmac-16kb-buffer-must-be-16-byte-aligned.patch
+net-stmmac-enable-16kb-buffer-size.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
+@@ -1165,6 +1165,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
+@@ -609,9 +609,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/intel_rdt.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/arch/x86/kernel/cpu/intel_rdt.c
++++ b/arch/x86/kernel/cpu/intel_rdt.c
+@@ -595,7 +595,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/intel_rdt_rdtgroup.c | 6 +++---
+ 1 file changed, 3 insertions(+), 3 deletions(-)
+
+--- a/arch/x86/kernel/cpu/intel_rdt_rdtgroup.c
++++ b/arch/x86/kernel/cpu/intel_rdt_rdtgroup.c
+@@ -1749,9 +1749,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)
+@@ -1759,6 +1756,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
