--- /dev/null
+From 221bfce5ebbdf72ff08b3bf2510ae81058ee568b Mon Sep 17 00:00:00 2001
+From: Kim Phillips <kim.phillips@amd.com>
+Date: Tue, 8 Sep 2020 16:47:36 -0500
+Subject: arch/x86/amd/ibs: Fix re-arming IBS Fetch
+
+From: Kim Phillips <kim.phillips@amd.com>
+
+commit 221bfce5ebbdf72ff08b3bf2510ae81058ee568b upstream.
+
+Stephane Eranian found a bug in that IBS' current Fetch counter was not
+being reset when the driver would write the new value to clear it along
+with the enable bit set, and found that adding an MSR write that would
+first disable IBS Fetch would make IBS Fetch reset its current count.
+
+Indeed, the PPR for AMD Family 17h Model 31h B0 55803 Rev 0.54 - Sep 12,
+2019 states "The periodic fetch counter is set to IbsFetchCnt [...] when
+IbsFetchEn is changed from 0 to 1."
+
+Explicitly set IbsFetchEn to 0 and then to 1 when re-enabling IBS Fetch,
+so the driver properly resets the internal counter to 0 and IBS
+Fetch starts counting again.
+
+A family 15h machine tested does not have this problem, and the extra
+wrmsr is also not needed on Family 19h, so only do the extra wrmsr on
+families 16h through 18h.
+
+Reported-by: Stephane Eranian <stephane.eranian@google.com>
+Signed-off-by: Kim Phillips <kim.phillips@amd.com>
+[peterz: optimized]
+Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
+Cc: stable@vger.kernel.org
+Link: https://bugzilla.kernel.org/show_bug.cgi?id=206537
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/x86/events/amd/ibs.c | 15 ++++++++++++++-
+ 1 file changed, 14 insertions(+), 1 deletion(-)
+
+--- a/arch/x86/events/amd/ibs.c
++++ b/arch/x86/events/amd/ibs.c
+@@ -89,6 +89,7 @@ struct perf_ibs {
+ u64 max_period;
+ unsigned long offset_mask[1];
+ int offset_max;
++ unsigned int fetch_count_reset_broken : 1;
+ struct cpu_perf_ibs __percpu *pcpu;
+
+ struct attribute **format_attrs;
+@@ -375,7 +376,12 @@ perf_ibs_event_update(struct perf_ibs *p
+ static inline void perf_ibs_enable_event(struct perf_ibs *perf_ibs,
+ struct hw_perf_event *hwc, u64 config)
+ {
+- wrmsrl(hwc->config_base, hwc->config | config | perf_ibs->enable_mask);
++ u64 tmp = hwc->config | config;
++
++ if (perf_ibs->fetch_count_reset_broken)
++ wrmsrl(hwc->config_base, tmp & ~perf_ibs->enable_mask);
++
++ wrmsrl(hwc->config_base, tmp | perf_ibs->enable_mask);
+ }
+
+ /*
+@@ -744,6 +750,13 @@ static __init void perf_event_ibs_init(v
+ {
+ struct attribute **attr = ibs_op_format_attrs;
+
++ /*
++ * Some chips fail to reset the fetch count when it is written; instead
++ * they need a 0-1 transition of IbsFetchEn.
++ */
++ if (boot_cpu_data.x86 >= 0x16 && boot_cpu_data.x86 <= 0x18)
++ perf_ibs_fetch.fetch_count_reset_broken = 1;
++
+ perf_ibs_pmu_init(&perf_ibs_fetch, "ibs_fetch");
+
+ if (ibs_caps & IBS_CAPS_OPCNT) {
--- /dev/null
+From df9c590986fdb6db9d5636d6cd93bc919c01b451 Mon Sep 17 00:00:00 2001
+From: Geert Uytterhoeven <geert+renesas@glider.be>
+Date: Thu, 17 Sep 2020 15:09:20 +0200
+Subject: ata: sata_rcar: Fix DMA boundary mask
+
+From: Geert Uytterhoeven <geert+renesas@glider.be>
+
+commit df9c590986fdb6db9d5636d6cd93bc919c01b451 upstream.
+
+Before commit 9495b7e92f716ab2 ("driver core: platform: Initialize
+dma_parms for platform devices"), the R-Car SATA device didn't have DMA
+parameters. Hence the DMA boundary mask supplied by its driver was
+silently ignored, as __scsi_init_queue() doesn't check the return value
+of dma_set_seg_boundary(), and the default value of 0xffffffff was used.
+
+Now the device has gained DMA parameters, the driver-supplied value is
+used, and the following warning is printed on Salvator-XS:
+
+ DMA-API: sata_rcar ee300000.sata: mapping sg segment across boundary [start=0x00000000ffffe000] [end=0x00000000ffffefff] [boundary=0x000000001ffffffe]
+ WARNING: CPU: 5 PID: 38 at kernel/dma/debug.c:1233 debug_dma_map_sg+0x298/0x300
+
+(the range of start/end values depend on whether IOMMU support is
+ enabled or not)
+
+The issue here is that SATA_RCAR_DMA_BOUNDARY doesn't have bit 0 set, so
+any typical end value, which is odd, will trigger the check.
+
+Fix this by increasing the DMA boundary value by 1.
+
+This also fixes the following WRITE DMA EXT timeout issue:
+
+ # dd if=/dev/urandom of=/mnt/de1/file1-1024M bs=1M count=1024
+ ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
+ ata1.00: failed command: WRITE DMA EXT
+ ata1.00: cmd 35/00:00:00:e6:0c/00:0a:00:00:00/e0 tag 0 dma 1310720 out
+ res 40/00:01:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
+ ata1.00: status: { DRDY }
+
+as seen by Shimoda-san since commit 429120f3df2dba2b ("block: fix
+splitting segments on boundary masks").
+
+Fixes: 8bfbeed58665dbbf ("sata_rcar: correct 'sata_rcar_sht'")
+Fixes: 9495b7e92f716ab2 ("driver core: platform: Initialize dma_parms for platform devices")
+Fixes: 429120f3df2dba2b ("block: fix splitting segments on boundary masks")
+Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
+Tested-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
+Tested-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
+Reviewed-by: Christoph Hellwig <hch@lst.de>
+Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Reviewed-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
+Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
+Cc: stable <stable@vger.kernel.org>
+Signed-off-by: Jens Axboe <axboe@kernel.dk>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/ata/sata_rcar.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/ata/sata_rcar.c
++++ b/drivers/ata/sata_rcar.c
+@@ -124,7 +124,7 @@
+ /* Descriptor table word 0 bit (when DTA32M = 1) */
+ #define SATA_RCAR_DTEND BIT(0)
+
+-#define SATA_RCAR_DMA_BOUNDARY 0x1FFFFFFEUL
++#define SATA_RCAR_DMA_BOUNDARY 0x1FFFFFFFUL
+
+ /* Gen2 Physical Layer Control Registers */
+ #define RCAR_GEN2_PHY_CTL1_REG 0x1704
--- /dev/null
+From 1aef5b4391f0c75c0a1523706a7b0311846ee12f Mon Sep 17 00:00:00 2001
+From: Song Liu <songliubraving@fb.com>
+Date: Thu, 10 Sep 2020 13:33:14 -0700
+Subject: bpf: Fix comment for helper bpf_current_task_under_cgroup()
+
+From: Song Liu <songliubraving@fb.com>
+
+commit 1aef5b4391f0c75c0a1523706a7b0311846ee12f upstream.
+
+This should be "current" not "skb".
+
+Fixes: c6b5fb8690fa ("bpf: add documentation for eBPF helpers (42-50)")
+Signed-off-by: Song Liu <songliubraving@fb.com>
+Signed-off-by: Alexei Starovoitov <ast@kernel.org>
+Cc: <stable@vger.kernel.org>
+Link: https://lore.kernel.org/bpf/20200910203314.70018-1-songliubraving@fb.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ include/uapi/linux/bpf.h | 4 ++--
+ tools/include/uapi/linux/bpf.h | 4 ++--
+ 2 files changed, 4 insertions(+), 4 deletions(-)
+
+--- a/include/uapi/linux/bpf.h
++++ b/include/uapi/linux/bpf.h
+@@ -1193,8 +1193,8 @@ union bpf_attr {
+ * Return
+ * The return value depends on the result of the test, and can be:
+ *
+- * * 0, if the *skb* task belongs to the cgroup2.
+- * * 1, if the *skb* task does not belong to the cgroup2.
++ * * 0, if current task belongs to the cgroup2.
++ * * 1, if current task does not belong to the cgroup2.
+ * * A negative error code, if an error occurred.
+ *
+ * int bpf_skb_change_tail(struct sk_buff *skb, u32 len, u64 flags)
+--- a/tools/include/uapi/linux/bpf.h
++++ b/tools/include/uapi/linux/bpf.h
+@@ -1191,8 +1191,8 @@ union bpf_attr {
+ * Return
+ * The return value depends on the result of the test, and can be:
+ *
+- * * 0, if the *skb* task belongs to the cgroup2.
+- * * 1, if the *skb* task does not belong to the cgroup2.
++ * * 0, if current task belongs to the cgroup2.
++ * * 1, if current task does not belong to the cgroup2.
+ * * A negative error code, if an error occurred.
+ *
+ * int bpf_skb_change_tail(struct sk_buff *skb, u32 len, u64 flags)
--- /dev/null
+From 40ac790d99c6dd16b367d5c2339e446a5f1b0593 Mon Sep 17 00:00:00 2001
+From: Frederic Barrat <fbarrat@linux.ibm.com>
+Date: Tue, 7 Apr 2020 13:56:01 +0200
+Subject: cxl: Rework error message for incompatible slots
+
+From: Frederic Barrat <fbarrat@linux.ibm.com>
+
+commit 40ac790d99c6dd16b367d5c2339e446a5f1b0593 upstream.
+
+Improve the error message shown if a capi adapter is plugged on a
+capi-incompatible slot directly under the PHB (no intermediate switch).
+
+Fixes: 5632874311db ("cxl: Add support for POWER9 DD2")
+Cc: stable@vger.kernel.org # 4.14+
+Signed-off-by: Frederic Barrat <fbarrat@linux.ibm.com>
+Reviewed-by: Andrew Donnellan <ajd@linux.ibm.com>
+Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
+Link: https://lore.kernel.org/r/20200407115601.25453-1-fbarrat@linux.ibm.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/misc/cxl/pci.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/drivers/misc/cxl/pci.c
++++ b/drivers/misc/cxl/pci.c
+@@ -397,8 +397,8 @@ int cxl_calc_capp_routing(struct pci_dev
+ *capp_unit_id = get_capp_unit_id(np, *phb_index);
+ of_node_put(np);
+ if (!*capp_unit_id) {
+- pr_err("cxl: invalid capp unit id (phb_index: %d)\n",
+- *phb_index);
++ pr_err("cxl: No capp unit found for PHB[%lld,%d]. Make sure the adapter is on a capi-compatible slot\n",
++ *chipid, *phb_index);
+ return -ENODEV;
+ }
+
--- /dev/null
+From 455b6c9112eff8d249e32ba165742085678a80a4 Mon Sep 17 00:00:00 2001
+From: Roberto Sassu <roberto.sassu@huawei.com>
+Date: Fri, 4 Sep 2020 11:23:30 +0200
+Subject: evm: Check size of security.evm before using it
+
+From: Roberto Sassu <roberto.sassu@huawei.com>
+
+commit 455b6c9112eff8d249e32ba165742085678a80a4 upstream.
+
+This patch checks the size for the EVM_IMA_XATTR_DIGSIG and
+EVM_XATTR_PORTABLE_DIGSIG types to ensure that the algorithm is read from
+the buffer returned by vfs_getxattr_alloc().
+
+Cc: stable@vger.kernel.org # 4.19.x
+Fixes: 5feeb61183dde ("evm: Allow non-SHA1 digital signatures")
+Signed-off-by: Roberto Sassu <roberto.sassu@huawei.com>
+Signed-off-by: Mimi Zohar <zohar@linux.ibm.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ security/integrity/evm/evm_main.c | 6 ++++++
+ 1 file changed, 6 insertions(+)
+
+--- a/security/integrity/evm/evm_main.c
++++ b/security/integrity/evm/evm_main.c
+@@ -186,6 +186,12 @@ static enum integrity_status evm_verify_
+ break;
+ case EVM_IMA_XATTR_DIGSIG:
+ case EVM_XATTR_PORTABLE_DIGSIG:
++ /* accept xattr with non-empty signature field */
++ if (xattr_len <= sizeof(struct signature_v2_hdr)) {
++ evm_status = INTEGRITY_FAIL;
++ goto out;
++ }
++
+ hdr = (struct signature_v2_hdr *)xattr_data;
+ digest.hdr.algo = hdr->hash_algo;
+ rc = evm_calc_hash(dentry, xattr_name, xattr_value,
--- /dev/null
+From d78092e4937de9ce55edcb4ee4c5e3c707be0190 Mon Sep 17 00:00:00 2001
+From: Miklos Szeredi <mszeredi@redhat.com>
+Date: Fri, 18 Sep 2020 10:36:50 +0200
+Subject: fuse: fix page dereference after free
+
+From: Miklos Szeredi <mszeredi@redhat.com>
+
+commit d78092e4937de9ce55edcb4ee4c5e3c707be0190 upstream.
+
+After unlock_request() pages from the ap->pages[] array may be put (e.g. by
+aborting the connection) and the pages can be freed.
+
+Prevent use after free by grabbing a reference to the page before calling
+unlock_request().
+
+The original patch was created by Pradeep P V K.
+
+Reported-by: Pradeep P V K <ppvk@codeaurora.org>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/fuse/dev.c | 28 ++++++++++++++++++----------
+ 1 file changed, 18 insertions(+), 10 deletions(-)
+
+--- a/fs/fuse/dev.c
++++ b/fs/fuse/dev.c
+@@ -853,15 +853,16 @@ static int fuse_try_move_page(struct fus
+ struct page *newpage;
+ struct pipe_buffer *buf = cs->pipebufs;
+
++ get_page(oldpage);
+ err = unlock_request(cs->req);
+ if (err)
+- return err;
++ goto out_put_old;
+
+ fuse_copy_finish(cs);
+
+ err = pipe_buf_confirm(cs->pipe, buf);
+ if (err)
+- return err;
++ goto out_put_old;
+
+ BUG_ON(!cs->nr_segs);
+ cs->currbuf = buf;
+@@ -901,7 +902,7 @@ static int fuse_try_move_page(struct fus
+ err = replace_page_cache_page(oldpage, newpage, GFP_KERNEL);
+ if (err) {
+ unlock_page(newpage);
+- return err;
++ goto out_put_old;
+ }
+
+ get_page(newpage);
+@@ -920,14 +921,19 @@ static int fuse_try_move_page(struct fus
+ if (err) {
+ unlock_page(newpage);
+ put_page(newpage);
+- return err;
++ goto out_put_old;
+ }
+
+ unlock_page(oldpage);
++ /* Drop ref for ap->pages[] array */
+ put_page(oldpage);
+ cs->len = 0;
+
+- return 0;
++ err = 0;
++out_put_old:
++ /* Drop ref obtained in this function */
++ put_page(oldpage);
++ return err;
+
+ out_fallback_unlock:
+ unlock_page(newpage);
+@@ -936,10 +942,10 @@ out_fallback:
+ cs->offset = buf->offset;
+
+ err = lock_request(cs->req);
+- if (err)
+- return err;
++ if (!err)
++ err = 1;
+
+- return 1;
++ goto out_put_old;
+ }
+
+ static int fuse_ref_page(struct fuse_copy_state *cs, struct page *page,
+@@ -951,14 +957,16 @@ static int fuse_ref_page(struct fuse_cop
+ if (cs->nr_segs == cs->pipe->buffers)
+ return -EIO;
+
++ get_page(page);
+ err = unlock_request(cs->req);
+- if (err)
++ if (err) {
++ put_page(page);
+ return err;
++ }
+
+ fuse_copy_finish(cs);
+
+ buf = cs->pipebufs;
+- get_page(page);
+ buf->page = page;
+ buf->offset = offset;
+ buf->len = count;
--- /dev/null
+From 1c9c02bb22684f6949d2e7ddc0a3ff364fd5a6fc Mon Sep 17 00:00:00 2001
+From: "Gustavo A. R. Silva" <gustavo@embeddedor.com>
+Date: Mon, 27 Apr 2020 14:50:37 -0500
+Subject: mtd: lpddr: Fix bad logic in print_drs_error
+
+From: Gustavo A. R. Silva <gustavo@embeddedor.com>
+
+commit 1c9c02bb22684f6949d2e7ddc0a3ff364fd5a6fc upstream.
+
+Update logic for broken test. Use a more common logging style.
+
+It appears the logic in this function is broken for the
+consecutive tests of
+
+ if (prog_status & 0x3)
+ ...
+ else if (prog_status & 0x2)
+ ...
+ else (prog_status & 0x1)
+ ...
+
+Likely the first test should be
+
+ if ((prog_status & 0x3) == 0x3)
+
+Found by inspection of include files using printk.
+
+Fixes: eb3db27507f7 ("[MTD] LPDDR PFOW definition")
+Cc: stable@vger.kernel.org
+Reported-by: Joe Perches <joe@perches.com>
+Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
+Acked-by: Miquel Raynal <miquel.raynal@bootlin.com>
+Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
+Link: https://lore.kernel.org/linux-mtd/3fb0e29f5b601db8be2938a01d974b00c8788501.1588016644.git.gustavo@embeddedor.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ include/linux/mtd/pfow.h | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/include/linux/mtd/pfow.h
++++ b/include/linux/mtd/pfow.h
+@@ -128,7 +128,7 @@ static inline void print_drs_error(unsig
+
+ if (!(dsr & DSR_AVAILABLE))
+ printk(KERN_NOTICE"DSR.15: (0) Device not Available\n");
+- if (prog_status & 0x03)
++ if ((prog_status & 0x03) == 0x03)
+ printk(KERN_NOTICE"DSR.9,8: (11) Attempt to program invalid "
+ "half with 41h command\n");
+ else if (prog_status & 0x02)
--- /dev/null
+From 478762855b5ae9f68fa6ead1edf7abada70fcd5f Mon Sep 17 00:00:00 2001
+From: Jia-Ju Bai <baijiaju@tsinghua.edu.cn>
+Date: Sun, 2 Aug 2020 21:29:49 +0800
+Subject: p54: avoid accessing the data mapped to streaming DMA
+
+From: Jia-Ju Bai <baijiaju@tsinghua.edu.cn>
+
+commit 478762855b5ae9f68fa6ead1edf7abada70fcd5f upstream.
+
+In p54p_tx(), skb->data is mapped to streaming DMA on line 337:
+ mapping = pci_map_single(..., skb->data, ...);
+
+Then skb->data is accessed on line 349:
+ desc->device_addr = ((struct p54_hdr *)skb->data)->req_id;
+
+This access may cause data inconsistency between CPU cache and hardware.
+
+To fix this problem, ((struct p54_hdr *)skb->data)->req_id is stored in
+a local variable before DMA mapping, and then the driver accesses this
+local variable instead of skb->data.
+
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Jia-Ju Bai <baijiaju@tsinghua.edu.cn>
+Acked-by: Christian Lamparter <chunkeey@gmail.com>
+Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
+Link: https://lore.kernel.org/r/20200802132949.26788-1-baijiaju@tsinghua.edu.cn
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/net/wireless/intersil/p54/p54pci.c | 4 +++-
+ 1 file changed, 3 insertions(+), 1 deletion(-)
+
+--- a/drivers/net/wireless/intersil/p54/p54pci.c
++++ b/drivers/net/wireless/intersil/p54/p54pci.c
+@@ -332,10 +332,12 @@ static void p54p_tx(struct ieee80211_hw
+ struct p54p_desc *desc;
+ dma_addr_t mapping;
+ u32 idx, i;
++ __le32 device_addr;
+
+ spin_lock_irqsave(&priv->lock, flags);
+ idx = le32_to_cpu(ring_control->host_idx[1]);
+ i = idx % ARRAY_SIZE(ring_control->tx_data);
++ device_addr = ((struct p54_hdr *)skb->data)->req_id;
+
+ mapping = pci_map_single(priv->pdev, skb->data, skb->len,
+ PCI_DMA_TODEVICE);
+@@ -349,7 +351,7 @@ static void p54p_tx(struct ieee80211_hw
+
+ desc = &ring_control->tx_data[i];
+ desc->host_addr = cpu_to_le32(mapping);
+- desc->device_addr = ((struct p54_hdr *)skb->data)->req_id;
++ desc->device_addr = device_addr;
+ desc->len = cpu_to_le16(skb->len);
+ desc->flags = 0;
+
--- /dev/null
+From 2ee9bf346fbfd1dad0933b9eb3a4c2c0979b633e Mon Sep 17 00:00:00 2001
+From: Jason Gunthorpe <jgg@nvidia.com>
+Date: Wed, 30 Sep 2020 10:20:07 +0300
+Subject: RDMA/addr: Fix race with netevent_callback()/rdma_addr_cancel()
+
+From: Jason Gunthorpe <jgg@nvidia.com>
+
+commit 2ee9bf346fbfd1dad0933b9eb3a4c2c0979b633e upstream.
+
+This three thread race can result in the work being run once the callback
+becomes NULL:
+
+ CPU1 CPU2 CPU3
+ netevent_callback()
+ process_one_req() rdma_addr_cancel()
+ [..]
+ spin_lock_bh()
+ set_timeout()
+ spin_unlock_bh()
+
+ spin_lock_bh()
+ list_del_init(&req->list);
+ spin_unlock_bh()
+
+ req->callback = NULL
+ spin_lock_bh()
+ if (!list_empty(&req->list))
+ // Skipped!
+ // cancel_delayed_work(&req->work);
+ spin_unlock_bh()
+
+ process_one_req() // again
+ req->callback() // BOOM
+ cancel_delayed_work_sync()
+
+The solution is to always cancel the work once it is completed so any
+in between set_timeout() does not result in it running again.
+
+Cc: stable@vger.kernel.org
+Fixes: 44e75052bc2a ("RDMA/rdma_cm: Make rdma_addr_cancel into a fence")
+Link: https://lore.kernel.org/r/20200930072007.1009692-1-leon@kernel.org
+Reported-by: Dan Aloni <dan@kernelim.com>
+Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
+Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/infiniband/core/addr.c | 11 +++++------
+ 1 file changed, 5 insertions(+), 6 deletions(-)
+
+--- a/drivers/infiniband/core/addr.c
++++ b/drivers/infiniband/core/addr.c
+@@ -571,13 +571,12 @@ static void process_one_req(struct work_
+ req->callback = NULL;
+
+ spin_lock_bh(&lock);
++ /*
++ * Although the work will normally have been canceled by the workqueue,
++ * it can still be requeued as long as it is on the req_list.
++ */
++ cancel_delayed_work(&req->work);
+ if (!list_empty(&req->list)) {
+- /*
+- * Although the work will normally have been canceled by the
+- * workqueue, it can still be requeued as long as it is on the
+- * req_list.
+- */
+- cancel_delayed_work(&req->work);
+ list_del_init(&req->list);
+ kfree(req);
+ }
--- /dev/null
+From 534cf755d9df99e214ddbe26b91cd4d81d2603e2 Mon Sep 17 00:00:00 2001
+From: Peter Zijlstra <peterz@infradead.org>
+Date: Wed, 30 Sep 2020 13:04:32 +0100
+Subject: serial: pl011: Fix lockdep splat when handling magic-sysrq interrupt
+
+From: Peter Zijlstra <peterz@infradead.org>
+
+commit 534cf755d9df99e214ddbe26b91cd4d81d2603e2 upstream.
+
+Issuing a magic-sysrq via the PL011 causes the following lockdep splat,
+which is easily reproducible under QEMU:
+
+ | sysrq: Changing Loglevel
+ | sysrq: Loglevel set to 9
+ |
+ | ======================================================
+ | WARNING: possible circular locking dependency detected
+ | 5.9.0-rc7 #1 Not tainted
+ | ------------------------------------------------------
+ | systemd-journal/138 is trying to acquire lock:
+ | ffffab133ad950c0 (console_owner){-.-.}-{0:0}, at: console_lock_spinning_enable+0x34/0x70
+ |
+ | but task is already holding lock:
+ | ffff0001fd47b098 (&port_lock_key){-.-.}-{2:2}, at: pl011_int+0x40/0x488
+ |
+ | which lock already depends on the new lock.
+
+ [...]
+
+ | Possible unsafe locking scenario:
+ |
+ | CPU0 CPU1
+ | ---- ----
+ | lock(&port_lock_key);
+ | lock(console_owner);
+ | lock(&port_lock_key);
+ | lock(console_owner);
+ |
+ | *** DEADLOCK ***
+
+The issue being that CPU0 takes 'port_lock' on the irq path in pl011_int()
+before taking 'console_owner' on the printk() path, whereas CPU1 takes
+the two locks in the opposite order on the printk() path due to setting
+the "console_owner" prior to calling into into the actual console driver.
+
+Fix this in the same way as the msm-serial driver by dropping 'port_lock'
+before handling the sysrq.
+
+Cc: <stable@vger.kernel.org> # 4.19+
+Cc: Russell King <linux@armlinux.org.uk>
+Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Cc: Jiri Slaby <jirislaby@kernel.org>
+Link: https://lore.kernel.org/r/20200811101313.GA6970@willie-the-truck
+Signed-off-by: Peter Zijlstra <peterz@infradead.org>
+Tested-by: Will Deacon <will@kernel.org>
+Signed-off-by: Will Deacon <will@kernel.org>
+Link: https://lore.kernel.org/r/20200930120432.16551-1-will@kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/tty/serial/amba-pl011.c | 11 +++++++----
+ 1 file changed, 7 insertions(+), 4 deletions(-)
+
+--- a/drivers/tty/serial/amba-pl011.c
++++ b/drivers/tty/serial/amba-pl011.c
+@@ -313,8 +313,9 @@ static void pl011_write(unsigned int val
+ */
+ static int pl011_fifo_to_tty(struct uart_amba_port *uap)
+ {
+- u16 status;
+ unsigned int ch, flag, fifotaken;
++ int sysrq;
++ u16 status;
+
+ for (fifotaken = 0; fifotaken != 256; fifotaken++) {
+ status = pl011_read(uap, REG_FR);
+@@ -349,10 +350,12 @@ static int pl011_fifo_to_tty(struct uart
+ flag = TTY_FRAME;
+ }
+
+- if (uart_handle_sysrq_char(&uap->port, ch & 255))
+- continue;
++ spin_unlock(&uap->port.lock);
++ sysrq = uart_handle_sysrq_char(&uap->port, ch & 255);
++ spin_lock(&uap->port.lock);
+
+- uart_insert_char(&uap->port, ch, UART011_DR_OE, ch, flag);
++ if (!sysrq)
++ uart_insert_char(&uap->port, ch, UART011_DR_OE, ch, flag);
+ }
+
+ return fifotaken;
tipc-fix-memory-leak-caused-by-tipc_buf_append.patch
r8169-fix-issue-with-forced-threading-in-combination-with-shared-interrupts.patch
cxgb4-set-up-filter-action-after-rewrites.patch
+arch-x86-amd-ibs-fix-re-arming-ibs-fetch.patch
+x86-xen-disable-firmware-first-mode-for-correctable-memory-errors.patch
+fuse-fix-page-dereference-after-free.patch
+bpf-fix-comment-for-helper-bpf_current_task_under_cgroup.patch
+evm-check-size-of-security.evm-before-using-it.patch
+p54-avoid-accessing-the-data-mapped-to-streaming-dma.patch
+cxl-rework-error-message-for-incompatible-slots.patch
+rdma-addr-fix-race-with-netevent_callback-rdma_addr_cancel.patch
+mtd-lpddr-fix-bad-logic-in-print_drs_error.patch
+serial-pl011-fix-lockdep-splat-when-handling-magic-sysrq-interrupt.patch
+ata-sata_rcar-fix-dma-boundary-mask.patch
--- /dev/null
+From d759af38572f97321112a0852353613d18126038 Mon Sep 17 00:00:00 2001
+From: Juergen Gross <jgross@suse.com>
+Date: Fri, 25 Sep 2020 16:07:51 +0200
+Subject: x86/xen: disable Firmware First mode for correctable memory errors
+
+From: Juergen Gross <jgross@suse.com>
+
+commit d759af38572f97321112a0852353613d18126038 upstream.
+
+When running as Xen dom0 the kernel isn't responsible for selecting the
+error handling mode, this should be handled by the hypervisor.
+
+So disable setting FF mode when running as Xen pv guest. Not doing so
+might result in boot splats like:
+
+[ 7.509696] HEST: Enabling Firmware First mode for corrected errors.
+[ 7.510382] mce: [Firmware Bug]: Ignoring request to disable invalid MCA bank 2.
+[ 7.510383] mce: [Firmware Bug]: Ignoring request to disable invalid MCA bank 3.
+[ 7.510384] mce: [Firmware Bug]: Ignoring request to disable invalid MCA bank 4.
+[ 7.510384] mce: [Firmware Bug]: Ignoring request to disable invalid MCA bank 5.
+[ 7.510385] mce: [Firmware Bug]: Ignoring request to disable invalid MCA bank 6.
+[ 7.510386] mce: [Firmware Bug]: Ignoring request to disable invalid MCA bank 7.
+[ 7.510386] mce: [Firmware Bug]: Ignoring request to disable invalid MCA bank 8.
+
+Reason is that the HEST ACPI table contains the real number of MCA
+banks, while the hypervisor is emulating only 2 banks for guests.
+
+Cc: stable@vger.kernel.org
+Signed-off-by: Juergen Gross <jgross@suse.com>
+Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
+Link: https://lore.kernel.org/r/20200925140751.31381-1-jgross@suse.com
+Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/x86/xen/enlighten_pv.c | 9 +++++++++
+ 1 file changed, 9 insertions(+)
+
+--- a/arch/x86/xen/enlighten_pv.c
++++ b/arch/x86/xen/enlighten_pv.c
+@@ -1383,6 +1383,15 @@ asmlinkage __visible void __init xen_sta
+ x86_init.mpparse.get_smp_config = x86_init_uint_noop;
+
+ xen_boot_params_init_edd();
++
++#ifdef CONFIG_ACPI
++ /*
++ * Disable selecting "Firmware First mode" for correctable
++ * memory errors, as this is the duty of the hypervisor to
++ * decide.
++ */
++ acpi_disable_cmcff = 1;
++#endif
+ }
+
+ if (!boot_params.screen_info.orig_video_isVGA)
projects / thirdparty / kernel / stable-queue.git / commitdiff
