--- /dev/null
+From d48d54ec517745c6fdeffaf9ef40b2b87af64834 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 5 May 2020 06:44:43 +0900
+Subject: ath9k_htc: Silence undersized packet warnings
+
+From: Masashi Honma <masashi.honma@gmail.com>
+
+[ Upstream commit 450edd2805982d14ed79733a82927d2857b27cac ]
+
+Some devices like TP-Link TL-WN722N produces this kind of messages
+frequently.
+
+kernel: ath: phy0: Short RX data len, dropping (dlen: 4)
+
+This warning is useful for developers to recognize that the device
+(Wi-Fi dongle or USB hub etc) is noisy but not for general users. So
+this patch make this warning to debug message.
+
+Reported-By: Denis <pro.denis@protonmail.com>
+Ref: https://bugzilla.kernel.org/show_bug.cgi?id=207539
+Fixes: cd486e627e67 ("ath9k_htc: Discard undersized packets")
+Signed-off-by: Masashi Honma <masashi.honma@gmail.com>
+Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
+Link: https://lore.kernel.org/r/20200504214443.4485-1-masashi.honma@gmail.com
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/wireless/ath/ath9k/htc_drv_txrx.c | 6 +++---
+ 1 file changed, 3 insertions(+), 3 deletions(-)
+
+diff --git a/drivers/net/wireless/ath/ath9k/htc_drv_txrx.c b/drivers/net/wireless/ath/ath9k/htc_drv_txrx.c
+index b5d7ef4da17f..f19393e584dc 100644
+--- a/drivers/net/wireless/ath/ath9k/htc_drv_txrx.c
++++ b/drivers/net/wireless/ath/ath9k/htc_drv_txrx.c
+@@ -999,9 +999,9 @@ static bool ath9k_rx_prepare(struct ath9k_htc_priv *priv,
+ * which are not PHY_ERROR (short radar pulses have a length of 3)
+ */
+ if (unlikely(!rs_datalen || (rs_datalen < 10 && !is_phyerr))) {
+- ath_warn(common,
+- "Short RX data len, dropping (dlen: %d)\n",
+- rs_datalen);
++ ath_dbg(common, ANY,
++ "Short RX data len, dropping (dlen: %d)\n",
++ rs_datalen);
+ goto rx_next;
+ }
+
+--
+2.25.1
+
--- /dev/null
+From b60747d2e215bbae12aee1140c683c8eb8ed9e34 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 4 Jun 2020 16:48:21 -0700
+Subject: mm: add kvfree_sensitive() for freeing sensitive data objects
+
+From: Waiman Long <longman@redhat.com>
+
+[ Upstream commit d4eaa2837851db2bfed572898bfc17f9a9f9151e ]
+
+For kvmalloc'ed data object that contains sensitive information like
+cryptographic keys, we need to make sure that the buffer is always cleared
+before freeing it. Using memset() alone for buffer clearing may not
+provide certainty as the compiler may compile it away. To be sure, the
+special memzero_explicit() has to be used.
+
+This patch introduces a new kvfree_sensitive() for freeing those sensitive
+data objects allocated by kvmalloc(). The relevant places where
+kvfree_sensitive() can be used are modified to use it.
+
+Fixes: 4f0882491a14 ("KEYS: Avoid false positive ENOMEM error on key read")
+Suggested-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Waiman Long <longman@redhat.com>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Reviewed-by: Eric Biggers <ebiggers@google.com>
+Acked-by: David Howells <dhowells@redhat.com>
+Cc: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
+Cc: James Morris <jmorris@namei.org>
+Cc: "Serge E. Hallyn" <serge@hallyn.com>
+Cc: Joe Perches <joe@perches.com>
+Cc: Matthew Wilcox <willy@infradead.org>
+Cc: David Rientjes <rientjes@google.com>
+Cc: Uladzislau Rezki <urezki@gmail.com>
+Link: http://lkml.kernel.org/r/20200407200318.11711-1-longman@redhat.com
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ include/linux/mm.h | 1 +
+ mm/util.c | 18 ++++++++++++++++++
+ security/keys/internal.h | 11 -----------
+ security/keys/keyctl.c | 16 +++++-----------
+ 4 files changed, 24 insertions(+), 22 deletions(-)
+
+diff --git a/include/linux/mm.h b/include/linux/mm.h
+index b1092046ebef..05bc5f25ab85 100644
+--- a/include/linux/mm.h
++++ b/include/linux/mm.h
+@@ -601,6 +601,7 @@ static inline void *kvcalloc(size_t n, size_t size, gfp_t flags)
+ }
+
+ extern void kvfree(const void *addr);
++extern void kvfree_sensitive(const void *addr, size_t len);
+
+ /*
+ * Mapcount of compound page as a whole, does not include mapped sub-pages.
+diff --git a/mm/util.c b/mm/util.c
+index 6a24a1025d77..621afcea2bfa 100644
+--- a/mm/util.c
++++ b/mm/util.c
+@@ -453,6 +453,24 @@ void kvfree(const void *addr)
+ }
+ EXPORT_SYMBOL(kvfree);
+
++/**
++ * kvfree_sensitive - Free a data object containing sensitive information.
++ * @addr: address of the data object to be freed.
++ * @len: length of the data object.
++ *
++ * Use the special memzero_explicit() function to clear the content of a
++ * kvmalloc'ed object containing sensitive data to make sure that the
++ * compiler won't optimize out the data clearing.
++ */
++void kvfree_sensitive(const void *addr, size_t len)
++{
++ if (likely(!ZERO_OR_NULL_PTR(addr))) {
++ memzero_explicit((void *)addr, len);
++ kvfree(addr);
++ }
++}
++EXPORT_SYMBOL(kvfree_sensitive);
++
+ static inline void *__page_rmapping(struct page *page)
+ {
+ unsigned long mapping;
+diff --git a/security/keys/internal.h b/security/keys/internal.h
+index eb50212fbbf8..d1b9c5957000 100644
+--- a/security/keys/internal.h
++++ b/security/keys/internal.h
+@@ -306,15 +306,4 @@ static inline void key_check(const struct key *key)
+ #define key_check(key) do {} while(0)
+
+ #endif
+-
+-/*
+- * Helper function to clear and free a kvmalloc'ed memory object.
+- */
+-static inline void __kvzfree(const void *addr, size_t len)
+-{
+- if (addr) {
+- memset((void *)addr, 0, len);
+- kvfree(addr);
+- }
+-}
+ #endif /* _INTERNAL_H */
+diff --git a/security/keys/keyctl.c b/security/keys/keyctl.c
+index c07c2e2b2478..9394d72a77e8 100644
+--- a/security/keys/keyctl.c
++++ b/security/keys/keyctl.c
+@@ -133,10 +133,7 @@ SYSCALL_DEFINE5(add_key, const char __user *, _type,
+
+ key_ref_put(keyring_ref);
+ error3:
+- if (payload) {
+- memzero_explicit(payload, plen);
+- kvfree(payload);
+- }
++ kvfree_sensitive(payload, plen);
+ error2:
+ kfree(description);
+ error:
+@@ -351,7 +348,7 @@ long keyctl_update_key(key_serial_t id,
+
+ key_ref_put(key_ref);
+ error2:
+- __kvzfree(payload, plen);
++ kvfree_sensitive(payload, plen);
+ error:
+ return ret;
+ }
+@@ -859,7 +856,7 @@ long keyctl_read_key(key_serial_t keyid, char __user *buffer, size_t buflen)
+ */
+ if (ret > key_data_len) {
+ if (unlikely(key_data))
+- __kvzfree(key_data, key_data_len);
++ kvfree_sensitive(key_data, key_data_len);
+ key_data_len = ret;
+ continue; /* Allocate buffer */
+ }
+@@ -868,7 +865,7 @@ long keyctl_read_key(key_serial_t keyid, char __user *buffer, size_t buflen)
+ ret = -EFAULT;
+ break;
+ }
+- __kvzfree(key_data, key_data_len);
++ kvfree_sensitive(key_data, key_data_len);
+
+ key_put_out:
+ key_put(key);
+@@ -1170,10 +1167,7 @@ long keyctl_instantiate_key_common(key_serial_t id,
+ keyctl_change_reqkey_auth(NULL);
+
+ error2:
+- if (payload) {
+- memzero_explicit(payload, plen);
+- kvfree(payload);
+- }
++ kvfree_sensitive(payload, plen);
+ error:
+ return ret;
+ }
+--
+2.25.1
+
--- /dev/null
+From c020667662a2f40535a4ddb4cd632ebf736c5f3b Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 6 May 2020 23:29:12 +0900
+Subject: perf probe: Accept the instance number of kretprobe event
+
+From: Masami Hiramatsu <mhiramat@kernel.org>
+
+[ Upstream commit c6aab66a728b6518772c74bd9dff66e1a1c652fd ]
+
+Since the commit 6a13a0d7b4d1 ("ftrace/kprobe: Show the maxactive number
+on kprobe_events") introduced to show the instance number of kretprobe
+events, the length of the 1st format of the kprobe event will not 1, but
+it can be longer. This caused a parser error in perf-probe.
+
+Skip the length check the 1st format of the kprobe event to accept this
+instance number.
+
+Without this fix:
+
+ # perf probe -a vfs_read%return
+ Added new event:
+ probe:vfs_read__return (on vfs_read%return)
+
+ You can now use it in all perf tools, such as:
+
+ perf record -e probe:vfs_read__return -aR sleep 1
+
+ # perf probe -l
+ Semantic error :Failed to parse event name: r16:probe/vfs_read__return
+ Error: Failed to show event list.
+
+And with this fixes:
+
+ # perf probe -a vfs_read%return
+ ...
+ # perf probe -l
+ probe:vfs_read__return (on vfs_read%return)
+
+Fixes: 6a13a0d7b4d1 ("ftrace/kprobe: Show the maxactive number on kprobe_events")
+Reported-by: Yuxuan Shui <yshuiv7@gmail.com>
+Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org>
+Tested-by: Yuxuan Shui <yshuiv7@gmail.com>
+Cc: Jiri Olsa <jolsa@redhat.com>
+Cc: Namhyung Kim <namhyung@kernel.org>
+Cc: stable@vger.kernel.org
+Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=207587
+Link: http://lore.kernel.org/lkml/158877535215.26469.1113127926699134067.stgit@devnote2
+Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ tools/perf/util/probe-event.c | 3 +--
+ 1 file changed, 1 insertion(+), 2 deletions(-)
+
+diff --git a/tools/perf/util/probe-event.c b/tools/perf/util/probe-event.c
+index a22e1f538aea..4dd79e08cb7b 100644
+--- a/tools/perf/util/probe-event.c
++++ b/tools/perf/util/probe-event.c
+@@ -1753,8 +1753,7 @@ int parse_probe_trace_command(const char *cmd, struct probe_trace_event *tev)
+ fmt1_str = strtok_r(argv0_str, ":", &fmt);
+ fmt2_str = strtok_r(NULL, "/", &fmt);
+ fmt3_str = strtok_r(NULL, " \t", &fmt);
+- if (fmt1_str == NULL || strlen(fmt1_str) != 1 || fmt2_str == NULL
+- || fmt3_str == NULL) {
++ if (fmt1_str == NULL || fmt2_str == NULL || fmt3_str == NULL) {
+ semantic_error("Failed to parse event name: %s\n", argv[0]);
+ ret = -EINVAL;
+ goto out;
+--
+2.25.1
+
--- /dev/null
+From 521ae9417ba7999ec46c5c277357de28ef073e06 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 29 Apr 2020 09:51:20 +0200
+Subject: powerpc/xive: Clear the page tables for the ESB IO mapping
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Cédric Le Goater <clg@kaod.org>
+
+[ Upstream commit a101950fcb78b0ba20cd487be6627dea58d55c2b ]
+
+Commit 1ca3dec2b2df ("powerpc/xive: Prevent page fault issues in the
+machine crash handler") fixed an issue in the FW assisted dump of
+machines using hash MMU and the XIVE interrupt mode under the POWER
+hypervisor. It forced the mapping of the ESB page of interrupts being
+mapped in the Linux IRQ number space to make sure the 'crash kexec'
+sequence worked during such an event. But it didn't handle the
+un-mapping.
+
+This mapping is now blocking the removal of a passthrough IO adapter
+under the POWER hypervisor because it expects the guest OS to have
+cleared all page table entries related to the adapter. If some are
+still present, the RTAS call which isolates the PCI slot returns error
+9001 "valid outstanding translations".
+
+Remove these mapping in the IRQ data cleanup routine.
+
+Under KVM, this cleanup is not required because the ESB pages for the
+adapter interrupts are un-mapped from the guest by the hypervisor in
+the KVM XIVE native device. This is now redundant but it's harmless.
+
+Fixes: 1ca3dec2b2df ("powerpc/xive: Prevent page fault issues in the machine crash handler")
+Cc: stable@vger.kernel.org # v5.5+
+Signed-off-by: Cédric Le Goater <clg@kaod.org>
+Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
+Link: https://lore.kernel.org/r/20200429075122.1216388-2-clg@kaod.org
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ arch/powerpc/sysdev/xive/common.c | 5 +++++
+ 1 file changed, 5 insertions(+)
+
+diff --git a/arch/powerpc/sysdev/xive/common.c b/arch/powerpc/sysdev/xive/common.c
+index 1c31a08cdd54..2aa9f3de223c 100644
+--- a/arch/powerpc/sysdev/xive/common.c
++++ b/arch/powerpc/sysdev/xive/common.c
+@@ -23,6 +23,7 @@
+ #include <linux/slab.h>
+ #include <linux/spinlock.h>
+ #include <linux/msi.h>
++#include <linux/vmalloc.h>
+
+ #include <asm/prom.h>
+ #include <asm/io.h>
+@@ -933,12 +934,16 @@ EXPORT_SYMBOL_GPL(is_xive_irq);
+ void xive_cleanup_irq_data(struct xive_irq_data *xd)
+ {
+ if (xd->eoi_mmio) {
++ unmap_kernel_range((unsigned long)xd->eoi_mmio,
++ 1u << xd->esb_shift);
+ iounmap(xd->eoi_mmio);
+ if (xd->eoi_mmio == xd->trig_mmio)
+ xd->trig_mmio = NULL;
+ xd->eoi_mmio = NULL;
+ }
+ if (xd->trig_mmio) {
++ unmap_kernel_range((unsigned long)xd->trig_mmio,
++ 1u << xd->esb_shift);
+ iounmap(xd->trig_mmio);
+ xd->trig_mmio = NULL;
+ }
+--
+2.25.1
+
--- /dev/null
+From f42e5e52b91cde3be6fdbfc051b7ae676835ecb9 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Mon, 6 Apr 2020 21:44:26 -0300
+Subject: RDMA/uverbs: Make the event_queue fds return POLLERR when
+ disassociated
+
+From: Jason Gunthorpe <jgg@mellanox.com>
+
+[ Upstream commit eb356e6dc15a30af604f052cd0e170450193c254 ]
+
+If is_closed is set, and the event list is empty, then read() will return
+-EIO without blocking. After setting is_closed in
+ib_uverbs_free_event_queue(), we do trigger a wake_up on the poll_wait,
+but the fops->poll() function does not check it, so poll will continue to
+sleep on an empty list.
+
+Fixes: 14e23bd6d221 ("RDMA/core: Fix locking in ib_uverbs_event_read")
+Link: https://lore.kernel.org/r/0-v1-ace813388969+48859-uverbs_poll_fix%25jgg@mellanox.com
+Reviewed-by: Leon Romanovsky <leonro@mellanox.com>
+Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/infiniband/core/uverbs_main.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+diff --git a/drivers/infiniband/core/uverbs_main.c b/drivers/infiniband/core/uverbs_main.c
+index 5404717998b0..fc4b46258c75 100644
+--- a/drivers/infiniband/core/uverbs_main.c
++++ b/drivers/infiniband/core/uverbs_main.c
+@@ -360,6 +360,8 @@ static __poll_t ib_uverbs_event_poll(struct ib_uverbs_event_queue *ev_queue,
+ spin_lock_irq(&ev_queue->lock);
+ if (!list_empty(&ev_queue->event_list))
+ pollflags = EPOLLIN | EPOLLRDNORM;
++ else if (ev_queue->is_closed)
++ pollflags = EPOLLERR;
+ spin_unlock_irq(&ev_queue->lock);
+
+ return pollflags;
+--
+2.25.1
+
sched-fair-don-t-numa-balance-for-kthreads.patch
input-synaptics-add-a-second-working-pnp_id-for-leno.patch
drivers-net-ibmvnic-update-vnic-protocol-version-rep.patch
+powerpc-xive-clear-the-page-tables-for-the-esb-io-ma.patch
+ath9k_htc-silence-undersized-packet-warnings.patch
+rdma-uverbs-make-the-event_queue-fds-return-pollerr-.patch
+x86-cpu-amd-make-erratum-1054-a-legacy-erratum.patch
+perf-probe-accept-the-instance-number-of-kretprobe-e.patch
+mm-add-kvfree_sensitive-for-freeing-sensitive-data-o.patch
--- /dev/null
+From cc3870235ad040f15d017b64ec1dfcbbb6a3277b Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 17 Apr 2020 09:33:56 -0500
+Subject: x86/cpu/amd: Make erratum #1054 a legacy erratum
+
+From: Kim Phillips <kim.phillips@amd.com>
+
+[ Upstream commit e2abfc0448a46d8a137505aa180caf14070ec535 ]
+
+Commit
+
+ 21b5ee59ef18 ("x86/cpu/amd: Enable the fixed Instructions Retired
+ counter IRPERF")
+
+mistakenly added erratum #1054 as an OS Visible Workaround (OSVW) ID 0.
+Erratum #1054 is not OSVW ID 0 [1], so make it a legacy erratum.
+
+There would never have been a false positive on older hardware that
+has OSVW bit 0 set, since the IRPERF feature was not available.
+
+However, save a couple of RDMSR executions per thread, on modern
+system configurations that correctly set non-zero values in their
+OSVW_ID_Length MSRs.
+
+[1] Revision Guide for AMD Family 17h Models 00h-0Fh Processors. The
+revision guide is available from the bugzilla link below.
+
+Fixes: 21b5ee59ef18 ("x86/cpu/amd: Enable the fixed Instructions Retired counter IRPERF")
+Reported-by: Andrew Cooper <andrew.cooper3@citrix.com>
+Signed-off-by: Kim Phillips <kim.phillips@amd.com>
+Signed-off-by: Borislav Petkov <bp@suse.de>
+Link: https://lkml.kernel.org/r/20200417143356.26054-1-kim.phillips@amd.com
+Link: https://bugzilla.kernel.org/show_bug.cgi?id=206537
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ arch/x86/kernel/cpu/amd.c | 3 +--
+ 1 file changed, 1 insertion(+), 2 deletions(-)
+
+diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu/amd.c
+index 120769955687..de69090ca142 100644
+--- a/arch/x86/kernel/cpu/amd.c
++++ b/arch/x86/kernel/cpu/amd.c
+@@ -1122,8 +1122,7 @@ static const int amd_erratum_383[] =
+
+ /* #1054: Instructions Retired Performance Counter May Be Inaccurate */
+ static const int amd_erratum_1054[] =
+- AMD_OSVW_ERRATUM(0, AMD_MODEL_RANGE(0x17, 0, 0, 0x2f, 0xf));
+-
++ AMD_LEGACY_ERRATUM(AMD_MODEL_RANGE(0x17, 0, 0, 0x2f, 0xf));
+
+ static bool cpu_has_amd_erratum(struct cpuinfo_x86 *cpu, const int *erratum)
+ {
+--
+2.25.1
+