--- /dev/null
+From 866af14eaacf6de198a0ba38ab736327ef431c32 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 19 May 2020 12:59:12 +0100
+Subject: ARM: 8978/1: mm: make act_mm() respect THREAD_SIZE
+
+From: Linus Walleij <linus.walleij@linaro.org>
+
+[ Upstream commit e1de94380af588bdf6ad6f0cc1f75004c35bc096 ]
+
+Recent work with KASan exposed the folling hard-coded bitmask
+in arch/arm/mm/proc-macros.S:
+
+ bic rd, sp, #8128
+ bic rd, rd, #63
+
+This forms the bitmask 0x1FFF that is coinciding with
+(PAGE_SIZE << THREAD_SIZE_ORDER) - 1, this code was assuming
+that THREAD_SIZE is always 8K (8192).
+
+As KASan was increasing THREAD_SIZE_ORDER to 2, I ran into
+this bug.
+
+Fix it by this little oneline suggested by Ard:
+
+ bic rd, sp, #(THREAD_SIZE - 1) & ~63
+
+Where THREAD_SIZE is defined using THREAD_SIZE_ORDER.
+
+We have to also include <linux/const.h> since the THREAD_SIZE
+expands to use the _AC() macro.
+
+Cc: Ard Biesheuvel <ardb@kernel.org>
+Cc: Florian Fainelli <f.fainelli@gmail.com>
+Suggested-by: Ard Biesheuvel <ardb@kernel.org>
+Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
+Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ arch/arm/mm/proc-macros.S | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+diff --git a/arch/arm/mm/proc-macros.S b/arch/arm/mm/proc-macros.S
+index 5461d589a1e2..60ac7c5999a9 100644
+--- a/arch/arm/mm/proc-macros.S
++++ b/arch/arm/mm/proc-macros.S
+@@ -5,6 +5,7 @@
+ * VMA_VM_FLAGS
+ * VM_EXEC
+ */
++#include <linux/const.h>
+ #include <asm/asm-offsets.h>
+ #include <asm/thread_info.h>
+
+@@ -30,7 +31,7 @@
+ * act_mm - get current->active_mm
+ */
+ .macro act_mm, rd
+- bic \rd, sp, #8128
++ bic \rd, sp, #(THREAD_SIZE - 1) & ~63
+ bic \rd, \rd, #63
+ ldr \rd, [\rd, #TI_TASK]
+ .if (TSK_ACTIVE_MM > IMM12_MASK)
+--
+2.25.1
+
--- /dev/null
+From afe825d326f72459bbf96dbce90cecf345e7cdbd Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 21 Apr 2020 09:10:56 -0400
+Subject: audit: fix a net reference leak in audit_list_rules_send()
+
+From: Paul Moore <paul@paul-moore.com>
+
+[ Upstream commit 3054d06719079388a543de6adb812638675ad8f5 ]
+
+If audit_list_rules_send() fails when trying to create a new thread
+to send the rules it also fails to cleanup properly, leaking a
+reference to a net structure. This patch fixes the error patch and
+renames audit_send_list() to audit_send_list_thread() to better
+match its cousin, audit_send_reply_thread().
+
+Reported-by: teroincn@gmail.com
+Reviewed-by: Richard Guy Briggs <rgb@redhat.com>
+Signed-off-by: Paul Moore <paul@paul-moore.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ kernel/audit.c | 2 +-
+ kernel/audit.h | 2 +-
+ kernel/auditfilter.c | 16 +++++++---------
+ 3 files changed, 9 insertions(+), 11 deletions(-)
+
+diff --git a/kernel/audit.c b/kernel/audit.c
+index 53224f399038..6faaa908544a 100644
+--- a/kernel/audit.c
++++ b/kernel/audit.c
+@@ -853,7 +853,7 @@ main_queue:
+ return 0;
+ }
+
+-int audit_send_list(void *_dest)
++int audit_send_list_thread(void *_dest)
+ {
+ struct audit_netlink_list *dest = _dest;
+ struct sk_buff *skb;
+diff --git a/kernel/audit.h b/kernel/audit.h
+index 9b110ae17ee3..1007773b0b81 100644
+--- a/kernel/audit.h
++++ b/kernel/audit.h
+@@ -248,7 +248,7 @@ struct audit_netlink_list {
+ struct sk_buff_head q;
+ };
+
+-int audit_send_list(void *_dest);
++int audit_send_list_thread(void *_dest);
+
+ extern int selinux_audit_rule_update(void);
+
+diff --git a/kernel/auditfilter.c b/kernel/auditfilter.c
+index 16cf396ea738..f26f4cb5d08d 100644
+--- a/kernel/auditfilter.c
++++ b/kernel/auditfilter.c
+@@ -1137,11 +1137,8 @@ int audit_rule_change(int type, int seq, void *data, size_t datasz)
+ */
+ int audit_list_rules_send(struct sk_buff *request_skb, int seq)
+ {
+- u32 portid = NETLINK_CB(request_skb).portid;
+- struct net *net = sock_net(NETLINK_CB(request_skb).sk);
+ struct task_struct *tsk;
+ struct audit_netlink_list *dest;
+- int err = 0;
+
+ /* We can't just spew out the rules here because we might fill
+ * the available socket buffer space and deadlock waiting for
+@@ -1149,25 +1146,26 @@ int audit_list_rules_send(struct sk_buff *request_skb, int seq)
+ * happen if we're actually running in the context of auditctl
+ * trying to _send_ the stuff */
+
+- dest = kmalloc(sizeof(struct audit_netlink_list), GFP_KERNEL);
++ dest = kmalloc(sizeof(*dest), GFP_KERNEL);
+ if (!dest)
+ return -ENOMEM;
+- dest->net = get_net(net);
+- dest->portid = portid;
++ dest->net = get_net(sock_net(NETLINK_CB(request_skb).sk));
++ dest->portid = NETLINK_CB(request_skb).portid;
+ skb_queue_head_init(&dest->q);
+
+ mutex_lock(&audit_filter_mutex);
+ audit_list_rules(seq, &dest->q);
+ mutex_unlock(&audit_filter_mutex);
+
+- tsk = kthread_run(audit_send_list, dest, "audit_send_list");
++ tsk = kthread_run(audit_send_list_thread, dest, "audit_send_list");
+ if (IS_ERR(tsk)) {
+ skb_queue_purge(&dest->q);
++ put_net(dest->net);
+ kfree(dest);
+- err = PTR_ERR(tsk);
++ return PTR_ERR(tsk);
+ }
+
+- return err;
++ return 0;
+ }
+
+ int audit_comparator(u32 left, u32 op, u32 right)
+--
+2.25.1
+
--- /dev/null
+From 7cf1d51153f78929eb8072cf7ba87bf3e0a6160a Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Mon, 20 Apr 2020 10:09:29 -0400
+Subject: audit: fix a net reference leak in audit_send_reply()
+
+From: Paul Moore <paul@paul-moore.com>
+
+[ Upstream commit a48b284b403a4a073d8beb72d2bb33e54df67fb6 ]
+
+If audit_send_reply() fails when trying to create a new thread to
+send the reply it also fails to cleanup properly, leaking a reference
+to a net structure. This patch fixes the error path and makes a
+handful of other cleanups that came up while fixing the code.
+
+Reported-by: teroincn@gmail.com
+Reviewed-by: Richard Guy Briggs <rgb@redhat.com>
+Signed-off-by: Paul Moore <paul@paul-moore.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ kernel/audit.c | 50 +++++++++++++++++++++++++++++---------------------
+ 1 file changed, 29 insertions(+), 21 deletions(-)
+
+diff --git a/kernel/audit.c b/kernel/audit.c
+index aa6d5e39526b..53224f399038 100644
+--- a/kernel/audit.c
++++ b/kernel/audit.c
+@@ -897,19 +897,30 @@ out_kfree_skb:
+ return NULL;
+ }
+
++static void audit_free_reply(struct audit_reply *reply)
++{
++ if (!reply)
++ return;
++
++ if (reply->skb)
++ kfree_skb(reply->skb);
++ if (reply->net)
++ put_net(reply->net);
++ kfree(reply);
++}
++
+ static int audit_send_reply_thread(void *arg)
+ {
+ struct audit_reply *reply = (struct audit_reply *)arg;
+- struct sock *sk = audit_get_sk(reply->net);
+
+ mutex_lock(&audit_cmd_mutex);
+ mutex_unlock(&audit_cmd_mutex);
+
+ /* Ignore failure. It'll only happen if the sender goes away,
+ because our timeout is set to infinite. */
+- netlink_unicast(sk, reply->skb, reply->portid, 0);
+- put_net(reply->net);
+- kfree(reply);
++ netlink_unicast(audit_get_sk(reply->net), reply->skb, reply->portid, 0);
++ reply->skb = NULL;
++ audit_free_reply(reply);
+ return 0;
+ }
+
+@@ -923,35 +934,32 @@ static int audit_send_reply_thread(void *arg)
+ * @payload: payload data
+ * @size: payload size
+ *
+- * Allocates an skb, builds the netlink message, and sends it to the port id.
+- * No failure notifications.
++ * Allocates a skb, builds the netlink message, and sends it to the port id.
+ */
+ static void audit_send_reply(struct sk_buff *request_skb, int seq, int type, int done,
+ int multi, const void *payload, int size)
+ {
+- struct net *net = sock_net(NETLINK_CB(request_skb).sk);
+- struct sk_buff *skb;
+ struct task_struct *tsk;
+- struct audit_reply *reply = kmalloc(sizeof(struct audit_reply),
+- GFP_KERNEL);
++ struct audit_reply *reply;
+
++ reply = kzalloc(sizeof(*reply), GFP_KERNEL);
+ if (!reply)
+ return;
+
+- skb = audit_make_reply(seq, type, done, multi, payload, size);
+- if (!skb)
+- goto out;
+-
+- reply->net = get_net(net);
++ reply->skb = audit_make_reply(seq, type, done, multi, payload, size);
++ if (!reply->skb)
++ goto err;
++ reply->net = get_net(sock_net(NETLINK_CB(request_skb).sk));
+ reply->portid = NETLINK_CB(request_skb).portid;
+- reply->skb = skb;
+
+ tsk = kthread_run(audit_send_reply_thread, reply, "audit_send_reply");
+- if (!IS_ERR(tsk))
+- return;
+- kfree_skb(skb);
+-out:
+- kfree(reply);
++ if (IS_ERR(tsk))
++ goto err;
++
++ return;
++
++err:
++ audit_free_reply(reply);
+ }
+
+ /*
+--
+2.25.1
+
--- /dev/null
+From f3e66a3468d800b5206a1cd44b844f7818c6f2ad Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 15 May 2020 17:27:04 +0800
+Subject: Bluetooth: Add SCO fallback for invalid LMP parameters error
+
+From: Hsin-Yu Chao <hychao@chromium.org>
+
+[ Upstream commit 56b5453a86203a44726f523b4133c1feca49ce7c ]
+
+Bluetooth PTS test case HFP/AG/ACC/BI-12-I accepts SCO connection
+with invalid parameter at the first SCO request expecting AG to
+attempt another SCO request with the use of "safe settings" for
+given codec, base on section 5.7.1.2 of HFP 1.7 specification.
+
+This patch addresses it by adding "Invalid LMP Parameters" (0x1e)
+to the SCO fallback case. Verified with below log:
+
+< HCI Command: Setup Synchronous Connection (0x01|0x0028) plen 17
+ Handle: 256
+ Transmit bandwidth: 8000
+ Receive bandwidth: 8000
+ Max latency: 13
+ Setting: 0x0003
+ Input Coding: Linear
+ Input Data Format: 1's complement
+ Input Sample Size: 8-bit
+ # of bits padding at MSB: 0
+ Air Coding Format: Transparent Data
+ Retransmission effort: Optimize for link quality (0x02)
+ Packet type: 0x0380
+ 3-EV3 may not be used
+ 2-EV5 may not be used
+ 3-EV5 may not be used
+> HCI Event: Command Status (0x0f) plen 4
+ Setup Synchronous Connection (0x01|0x0028) ncmd 1
+ Status: Success (0x00)
+> HCI Event: Number of Completed Packets (0x13) plen 5
+ Num handles: 1
+ Handle: 256
+ Count: 1
+> HCI Event: Max Slots Change (0x1b) plen 3
+ Handle: 256
+ Max slots: 1
+> HCI Event: Synchronous Connect Complete (0x2c) plen 17
+ Status: Invalid LMP Parameters / Invalid LL Parameters (0x1e)
+ Handle: 0
+ Address: 00:1B:DC:F2:21:59 (OUI 00-1B-DC)
+ Link type: eSCO (0x02)
+ Transmission interval: 0x00
+ Retransmission window: 0x02
+ RX packet length: 0
+ TX packet length: 0
+ Air mode: Transparent (0x03)
+< HCI Command: Setup Synchronous Connection (0x01|0x0028) plen 17
+ Handle: 256
+ Transmit bandwidth: 8000
+ Receive bandwidth: 8000
+ Max latency: 8
+ Setting: 0x0003
+ Input Coding: Linear
+ Input Data Format: 1's complement
+ Input Sample Size: 8-bit
+ # of bits padding at MSB: 0
+ Air Coding Format: Transparent Data
+ Retransmission effort: Optimize for link quality (0x02)
+ Packet type: 0x03c8
+ EV3 may be used
+ 2-EV3 may not be used
+ 3-EV3 may not be used
+ 2-EV5 may not be used
+ 3-EV5 may not be used
+> HCI Event: Command Status (0x0f) plen 4
+ Setup Synchronous Connection (0x01|0x0028) ncmd 1
+ Status: Success (0x00)
+> HCI Event: Max Slots Change (0x1b) plen 3
+ Handle: 256
+ Max slots: 5
+> HCI Event: Max Slots Change (0x1b) plen 3
+ Handle: 256
+ Max slots: 1
+> HCI Event: Synchronous Connect Complete (0x2c) plen 17
+ Status: Success (0x00)
+ Handle: 257
+ Address: 00:1B:DC:F2:21:59 (OUI 00-1B-DC)
+ Link type: eSCO (0x02)
+ Transmission interval: 0x06
+ Retransmission window: 0x04
+ RX packet length: 30
+ TX packet length: 30
+ Air mode: Transparent (0x03)
+
+Signed-off-by: Hsin-Yu Chao <hychao@chromium.org>
+Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ net/bluetooth/hci_event.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c
+index 363dc85bbc5c..56e4ae7d7f63 100644
+--- a/net/bluetooth/hci_event.c
++++ b/net/bluetooth/hci_event.c
+@@ -3775,6 +3775,7 @@ static void hci_sync_conn_complete_evt(struct hci_dev *hdev,
+ case 0x11: /* Unsupported Feature or Parameter Value */
+ case 0x1c: /* SCO interval rejected */
+ case 0x1a: /* Unsupported Remote Feature */
++ case 0x1e: /* Invalid LMP Parameters */
+ case 0x1f: /* Unspecified error */
+ case 0x20: /* Unsupported LMP Parameter value */
+ if (conn->out) {
+--
+2.25.1
+
--- /dev/null
+From 459748c45c9ca00c0c81d6a020abbbebae38e5d0 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Mon, 30 Mar 2020 14:25:28 +0900
+Subject: brcmfmac: fix wrong location to get firmware feature
+
+From: Jaehoon Chung <jh80.chung@samsung.com>
+
+[ Upstream commit c57673852062428cdeabdd6501ac8b8e4c302067 ]
+
+sup_wpa feature is getting after setting feature_disable flag.
+If firmware is supported sup_wpa feature, it's always enabled
+regardless of feature_disable flag.
+
+Fixes: b8a64f0e96c2 ("brcmfmac: support 4-way handshake offloading for WPA/WPA2-PSK")
+Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>
+Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
+Link: https://lore.kernel.org/r/20200330052528.10503-1-jh80.chung@samsung.com
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/wireless/broadcom/brcm80211/brcmfmac/feature.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/feature.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/feature.c
+index 53ae30259989..473b2b3cb6f5 100644
+--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/feature.c
++++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/feature.c
+@@ -192,13 +192,14 @@ void brcmf_feat_attach(struct brcmf_pub *drvr)
+ if (!err)
+ ifp->drvr->feat_flags |= BIT(BRCMF_FEAT_SCAN_RANDOM_MAC);
+
++ brcmf_feat_iovar_int_get(ifp, BRCMF_FEAT_FWSUP, "sup_wpa");
++
+ if (drvr->settings->feature_disable) {
+ brcmf_dbg(INFO, "Features: 0x%02x, disable: 0x%02x\n",
+ ifp->drvr->feat_flags,
+ drvr->settings->feature_disable);
+ ifp->drvr->feat_flags &= ~drvr->settings->feature_disable;
+ }
+- brcmf_feat_iovar_int_get(ifp, BRCMF_FEAT_FWSUP, "sup_wpa");
+
+ /* set chip related quirks */
+ switch (drvr->bus_if->chip) {
+--
+2.25.1
+
--- /dev/null
+From 6db736d6d21e7ae609f51b1976bd5673ce5dad2c Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Mon, 18 May 2020 12:15:09 +0100
+Subject: btrfs: do not ignore error from btrfs_next_leaf() when inserting
+ checksums
+
+From: Filipe Manana <fdmanana@suse.com>
+
+[ Upstream commit 7e4a3f7ed5d54926ec671bbb13e171cfe179cc50 ]
+
+We are currently treating any non-zero return value from btrfs_next_leaf()
+the same way, by going to the code that inserts a new checksum item in the
+tree. However if btrfs_next_leaf() returns an error (a value < 0), we
+should just stop and return the error, and not behave as if nothing has
+happened, since in that case we do not have a way to know if there is a
+next leaf or we are currently at the last leaf already.
+
+So fix that by returning the error from btrfs_next_leaf().
+
+Signed-off-by: Filipe Manana <fdmanana@suse.com>
+Reviewed-by: David Sterba <dsterba@suse.com>
+Signed-off-by: David Sterba <dsterba@suse.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ fs/btrfs/file-item.c | 6 ++++--
+ 1 file changed, 4 insertions(+), 2 deletions(-)
+
+diff --git a/fs/btrfs/file-item.c b/fs/btrfs/file-item.c
+index 717d82d51bb1..edd5f152e448 100644
+--- a/fs/btrfs/file-item.c
++++ b/fs/btrfs/file-item.c
+@@ -795,10 +795,12 @@ again:
+ nritems = btrfs_header_nritems(path->nodes[0]);
+ if (!nritems || (path->slots[0] >= nritems - 1)) {
+ ret = btrfs_next_leaf(root, path);
+- if (ret == 1)
++ if (ret < 0) {
++ goto out;
++ } else if (ret > 0) {
+ found_next = 1;
+- if (ret != 0)
+ goto insert;
++ }
+ slot = path->slots[0];
+ }
+ btrfs_item_key_to_cpu(path->nodes[0], &found_key, slot);
+--
+2.25.1
+
--- /dev/null
+From 6cb2266a8055b786e1b61695ec8fda46f5540338 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 21 May 2020 23:48:13 +0300
+Subject: clocksource: dw_apb_timer: Make CPU-affiliation being optional
+
+From: Serge Semin <Sergey.Semin@baikalelectronics.ru>
+
+[ Upstream commit cee43dbf2ee3f430434e2b66994eff8a1aeda889 ]
+
+Currently the DW APB Timer driver binds each clockevent timers to a
+particular CPU. This isn't good for multiple reasons. First of all seeing
+the device is placed on APB bus (which makes it accessible from any CPU
+core), accessible over MMIO and having the DYNIRQ flag set we can be sure
+that manually binding the timer to any CPU just isn't correct. By doing
+so we just set an extra limitation on device usage. This also doesn't
+reflect the device actual capability, since by setting the IRQ affinity
+we can make it virtually local to any CPU. Secondly imagine if you had a
+real CPU-local timer with the same rating and the same CPU-affinity.
+In this case if DW APB timer was registered first, then due to the
+clockevent framework tick-timer selection procedure we'll end up with the
+real CPU-local timer being left unselected for clock-events tracking. But
+on most of the platforms (MIPS/ARM/etc) such timers are normally embedded
+into the CPU core and are accessible with much better performance then
+devices placed on APB. For instance in MIPS architectures there is
+r4k-timer, which is CPU-local, assigned with the same rating, and normally
+its clockevent device is registered after the platform-specific one.
+
+So in order to fix all of these issues let's make the DW APB Timer CPU
+affinity being optional and deactivated by passing a negative CPU id,
+which will effectively set the DW APB clockevent timer cpumask to
+'cpu_possible_mask'.
+
+Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
+Cc: Alexey Malahov <Alexey.Malahov@baikalelectronics.ru>
+Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
+Cc: Paul Burton <paulburton@kernel.org>
+Cc: Ralf Baechle <ralf@linux-mips.org>
+Cc: Alessandro Zummo <a.zummo@towertech.it>
+Cc: Alexandre Belloni <alexandre.belloni@bootlin.com>
+Cc: Arnd Bergmann <arnd@arndb.de>
+Cc: Rob Herring <robh+dt@kernel.org>
+Cc: linux-mips@vger.kernel.org
+Cc: linux-rtc@vger.kernel.org
+Cc: devicetree@vger.kernel.org
+Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
+Link: https://lore.kernel.org/r/20200521204818.25436-5-Sergey.Semin@baikalelectronics.ru
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/clocksource/dw_apb_timer.c | 5 +++--
+ 1 file changed, 3 insertions(+), 2 deletions(-)
+
+diff --git a/drivers/clocksource/dw_apb_timer.c b/drivers/clocksource/dw_apb_timer.c
+index 1f5f734e4919..a018199575e3 100644
+--- a/drivers/clocksource/dw_apb_timer.c
++++ b/drivers/clocksource/dw_apb_timer.c
+@@ -225,7 +225,8 @@ static int apbt_next_event(unsigned long delta,
+ /**
+ * dw_apb_clockevent_init() - use an APB timer as a clock_event_device
+ *
+- * @cpu: The CPU the events will be targeted at.
++ * @cpu: The CPU the events will be targeted at or -1 if CPU affiliation
++ * isn't required.
+ * @name: The name used for the timer and the IRQ for it.
+ * @rating: The rating to give the timer.
+ * @base: I/O base for the timer registers.
+@@ -260,7 +261,7 @@ dw_apb_clockevent_init(int cpu, const char *name, unsigned rating,
+ dw_ced->ced.max_delta_ticks = 0x7fffffff;
+ dw_ced->ced.min_delta_ns = clockevent_delta2ns(5000, &dw_ced->ced);
+ dw_ced->ced.min_delta_ticks = 5000;
+- dw_ced->ced.cpumask = cpumask_of(cpu);
++ dw_ced->ced.cpumask = cpu < 0 ? cpu_possible_mask : cpumask_of(cpu);
+ dw_ced->ced.features = CLOCK_EVT_FEAT_PERIODIC |
+ CLOCK_EVT_FEAT_ONESHOT | CLOCK_EVT_FEAT_DYNIRQ;
+ dw_ced->ced.set_state_shutdown = apbt_shutdown;
+--
+2.25.1
+
--- /dev/null
+From 677cae9dff32b6ee3ac4abb964bc67ee8ec081a9 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 21 May 2020 23:48:15 +0300
+Subject: clocksource: dw_apb_timer_of: Fix missing clockevent timers
+
+From: Serge Semin <Sergey.Semin@baikalelectronics.ru>
+
+[ Upstream commit 6d2e16a3181bafb77b535095c39ad1c8b9558c8c ]
+
+Commit 100214889973 ("clocksource: dw_apb_timer_of: use
+clocksource_of_init") replaced a publicly available driver
+initialization method with one called by the timer_probe() method
+available after CLKSRC_OF. In current implementation it traverses
+all the timers available in the system and calls their initialization
+methods if corresponding devices were either in dtb or in acpi. But
+if before the commit any number of available timers would be installed
+as clockevent and clocksource devices, after that there would be at most
+two. The rest are just ignored since default case branch doesn't do
+anything. I don't see a reason of such behaviour, neither the commit
+message explains it. Moreover this might be wrong if on some platforms
+these timers might be used for different purpose, as virtually CPU-local
+clockevent timers and as an independent broadcast timer. So in order
+to keep the compatibility with the platforms where the order of the
+timers detection has some meaning, lets add the secondly discovered
+timer to be of clocksource/sched_clock type, while the very first and
+the others would provide the clockevents service.
+
+Fixes: 100214889973 ("clocksource: dw_apb_timer_of: use clocksource_of_init")
+Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
+Cc: Alexey Malahov <Alexey.Malahov@baikalelectronics.ru>
+Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
+Cc: Paul Burton <paulburton@kernel.org>
+Cc: Ralf Baechle <ralf@linux-mips.org>
+Cc: Alessandro Zummo <a.zummo@towertech.it>
+Cc: Alexandre Belloni <alexandre.belloni@bootlin.com>
+Cc: Arnd Bergmann <arnd@arndb.de>
+Cc: Rob Herring <robh+dt@kernel.org>
+Cc: linux-mips@vger.kernel.org
+Cc: linux-rtc@vger.kernel.org
+Cc: devicetree@vger.kernel.org
+Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
+Link: https://lore.kernel.org/r/20200521204818.25436-7-Sergey.Semin@baikalelectronics.ru
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/clocksource/dw_apb_timer_of.c | 6 ++----
+ 1 file changed, 2 insertions(+), 4 deletions(-)
+
+diff --git a/drivers/clocksource/dw_apb_timer_of.c b/drivers/clocksource/dw_apb_timer_of.c
+index 69866cd8f4bb..3e4d0e5733d3 100644
+--- a/drivers/clocksource/dw_apb_timer_of.c
++++ b/drivers/clocksource/dw_apb_timer_of.c
+@@ -146,10 +146,6 @@ static int num_called;
+ static int __init dw_apb_timer_init(struct device_node *timer)
+ {
+ switch (num_called) {
+- case 0:
+- pr_debug("%s: found clockevent timer\n", __func__);
+- add_clockevent(timer);
+- break;
+ case 1:
+ pr_debug("%s: found clocksource timer\n", __func__);
+ add_clocksource(timer);
+@@ -160,6 +156,8 @@ static int __init dw_apb_timer_init(struct device_node *timer)
+ #endif
+ break;
+ default:
++ pr_debug("%s: found clockevent timer\n", __func__);
++ add_clockevent(timer);
+ break;
+ }
+
+--
+2.25.1
+
--- /dev/null
+From 33b2d6979bfbc7dbc97e484a0fec1614d70c54f3 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 28 May 2020 13:20:46 -0500
+Subject: cpuidle: Fix three reference count leaks
+
+From: Qiushi Wu <wu000273@umn.edu>
+
+[ Upstream commit c343bf1ba5efcbf2266a1fe3baefec9cc82f867f ]
+
+kobject_init_and_add() takes reference even when it fails.
+If this function returns an error, kobject_put() must be called to
+properly clean up the memory associated with the object.
+
+Previous commit "b8eb718348b8" fixed a similar problem.
+
+Signed-off-by: Qiushi Wu <wu000273@umn.edu>
+[ rjw: Subject ]
+Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/cpuidle/sysfs.c | 6 +++---
+ 1 file changed, 3 insertions(+), 3 deletions(-)
+
+diff --git a/drivers/cpuidle/sysfs.c b/drivers/cpuidle/sysfs.c
+index ae948b1da93a..909bd2255978 100644
+--- a/drivers/cpuidle/sysfs.c
++++ b/drivers/cpuidle/sysfs.c
+@@ -414,7 +414,7 @@ static int cpuidle_add_state_sysfs(struct cpuidle_device *device)
+ ret = kobject_init_and_add(&kobj->kobj, &ktype_state_cpuidle,
+ &kdev->kobj, "state%d", i);
+ if (ret) {
+- kfree(kobj);
++ kobject_put(&kobj->kobj);
+ goto error_state;
+ }
+ kobject_uevent(&kobj->kobj, KOBJ_ADD);
+@@ -544,7 +544,7 @@ static int cpuidle_add_driver_sysfs(struct cpuidle_device *dev)
+ ret = kobject_init_and_add(&kdrv->kobj, &ktype_driver_cpuidle,
+ &kdev->kobj, "driver");
+ if (ret) {
+- kfree(kdrv);
++ kobject_put(&kdrv->kobj);
+ return ret;
+ }
+
+@@ -638,7 +638,7 @@ int cpuidle_add_sysfs(struct cpuidle_device *dev)
+ error = kobject_init_and_add(&kdev->kobj, &ktype_cpuidle, &cpu_dev->kobj,
+ "cpuidle");
+ if (error) {
+- kfree(kdev);
++ kobject_put(&kdev->kobj);
+ return error;
+ }
+
+--
+2.25.1
+
--- /dev/null
+From 9fc1bdf9450af1384e75e94fe362a2f4d50c888f Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 8 Apr 2020 18:26:48 +0200
+Subject: crypto: ccp -- don't "select" CONFIG_DMADEVICES
+
+From: Arnd Bergmann <arnd@arndb.de>
+
+[ Upstream commit eebac678556d6927f09a992872f4464cf3aecc76 ]
+
+DMADEVICES is the top-level option for the slave DMA
+subsystem, and should not be selected by device drivers,
+as this can cause circular dependencies such as:
+
+drivers/net/ethernet/freescale/Kconfig:6:error: recursive dependency detected!
+drivers/net/ethernet/freescale/Kconfig:6: symbol NET_VENDOR_FREESCALE depends on PPC_BESTCOMM
+drivers/dma/bestcomm/Kconfig:6: symbol PPC_BESTCOMM depends on DMADEVICES
+drivers/dma/Kconfig:6: symbol DMADEVICES is selected by CRYPTO_DEV_SP_CCP
+drivers/crypto/ccp/Kconfig:10: symbol CRYPTO_DEV_SP_CCP depends on CRYPTO
+crypto/Kconfig:16: symbol CRYPTO is selected by LIBCRC32C
+lib/Kconfig:222: symbol LIBCRC32C is selected by LIQUIDIO
+drivers/net/ethernet/cavium/Kconfig:65: symbol LIQUIDIO depends on PTP_1588_CLOCK
+drivers/ptp/Kconfig:8: symbol PTP_1588_CLOCK is implied by FEC
+drivers/net/ethernet/freescale/Kconfig:23: symbol FEC depends on NET_VENDOR_FREESCALE
+
+The LIQUIDIO driver causing this problem is addressed in a
+separate patch, but this change is needed to prevent it from
+happening again.
+
+Using "depends on DMADEVICES" is what we do for all other
+implementations of slave DMA controllers as well.
+
+Fixes: b3c2fee5d66b ("crypto: ccp - Ensure all dependencies are specified")
+Signed-off-by: Arnd Bergmann <arnd@arndb.de>
+Acked-by: Tom Lendacky <thomas.lendacky@amd.com>
+Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/crypto/ccp/Kconfig | 3 +--
+ 1 file changed, 1 insertion(+), 2 deletions(-)
+
+diff --git a/drivers/crypto/ccp/Kconfig b/drivers/crypto/ccp/Kconfig
+index 6d626606b9c5..898dcf3200c3 100644
+--- a/drivers/crypto/ccp/Kconfig
++++ b/drivers/crypto/ccp/Kconfig
+@@ -8,10 +8,9 @@ config CRYPTO_DEV_CCP_DD
+ config CRYPTO_DEV_SP_CCP
+ bool "Cryptographic Coprocessor device"
+ default y
+- depends on CRYPTO_DEV_CCP_DD
++ depends on CRYPTO_DEV_CCP_DD && DMADEVICES
+ select HW_RANDOM
+ select DMA_ENGINE
+- select DMADEVICES
+ select CRYPTO_SHA1
+ select CRYPTO_SHA256
+ help
+--
+2.25.1
+
--- /dev/null
+From cde362973deb0d3de32bb676def8c4ba41e4b02c Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 5 May 2020 08:42:55 +0530
+Subject: Crypto/chcr: fix for ccm(aes) failed test
+
+From: Devulapally Shiva Krishna <shiva@chelsio.com>
+
+[ Upstream commit 10b0c75d7bc19606fa9a62c8ab9180e95c0e0385 ]
+
+The ccm(aes) test fails when req->assoclen > ~240bytes.
+
+The problem is the value assigned to auth_offset is wrong.
+As auth_offset is unsigned char, it can take max value as 255.
+So fix it by making it unsigned int.
+
+Signed-off-by: Ayush Sawal <ayush.sawal@chelsio.com>
+Signed-off-by: Devulapally Shiva Krishna <shiva@chelsio.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/crypto/chelsio/chcr_algo.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/drivers/crypto/chelsio/chcr_algo.c b/drivers/crypto/chelsio/chcr_algo.c
+index 8d39f3a07bf8..99c3827855c7 100644
+--- a/drivers/crypto/chelsio/chcr_algo.c
++++ b/drivers/crypto/chelsio/chcr_algo.c
+@@ -2201,7 +2201,7 @@ static void fill_sec_cpl_for_aead(struct cpl_tx_sec_pdu *sec_cpl,
+ unsigned int mac_mode = CHCR_SCMD_AUTH_MODE_CBCMAC;
+ unsigned int c_id = chcrctx->dev->rx_channel_id;
+ unsigned int ccm_xtra;
+- unsigned char tag_offset = 0, auth_offset = 0;
++ unsigned int tag_offset = 0, auth_offset = 0;
+ unsigned int assoclen;
+
+ if (get_aead_subtype(tfm) == CRYPTO_ALG_SUB_TYPE_AEAD_RFC4309)
+--
+2.25.1
+
--- /dev/null
+From 1e8f1e316a019e3a13638e0b13ea6098ab9be2f9 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Mon, 13 Apr 2020 14:35:08 +0300
+Subject: drm: bridge: adv7511: Extend list of audio sample rates
+
+From: Bogdan Togorean <bogdan.togorean@analog.com>
+
+[ Upstream commit b97b6a1f6e14a25d1e1ca2a46c5fa3e2ca374e22 ]
+
+ADV7511 support sample rates up to 192kHz. CTS and N parameters should
+be computed accordingly so this commit extend the list up to maximum
+supported sample rate.
+
+Signed-off-by: Bogdan Togorean <bogdan.togorean@analog.com>
+Reviewed-by: Andrzej Hajda <a.hajda@samsung.com>
+Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
+Link: https://patchwork.freedesktop.org/patch/msgid/20200413113513.86091-2-bogdan.togorean@analog.com
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/gpu/drm/bridge/adv7511/adv7511_audio.c | 12 +++++++-----
+ 1 file changed, 7 insertions(+), 5 deletions(-)
+
+diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_audio.c b/drivers/gpu/drm/bridge/adv7511/adv7511_audio.c
+index 67469c26bae8..45a027d7a1e4 100644
+--- a/drivers/gpu/drm/bridge/adv7511/adv7511_audio.c
++++ b/drivers/gpu/drm/bridge/adv7511/adv7511_audio.c
+@@ -20,13 +20,15 @@ static void adv7511_calc_cts_n(unsigned int f_tmds, unsigned int fs,
+ {
+ switch (fs) {
+ case 32000:
+- *n = 4096;
++ case 48000:
++ case 96000:
++ case 192000:
++ *n = fs * 128 / 1000;
+ break;
+ case 44100:
+- *n = 6272;
+- break;
+- case 48000:
+- *n = 6144;
++ case 88200:
++ case 176400:
++ *n = fs * 128 / 900;
+ break;
+ }
+
+--
+2.25.1
+
--- /dev/null
+From 557a7688b50d8de601db4e1078a3baa096605eac Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 15 Apr 2020 09:13:17 +0800
+Subject: dt-bindings: display: mediatek: control dpi pins mode to avoid
+ leakage
+
+From: Jitao Shi <jitao.shi@mediatek.com>
+
+[ Upstream commit b0ff9b590733079f7f9453e5976a9dd2630949e3 ]
+
+Add property "pinctrl-names" to swap pin mode between gpio and dpi mode.
+Set the dpi pins to gpio mode and output-low to avoid leakage current
+when dpi disabled.
+
+Acked-by: Rob Herring <robh@kernel.org>
+Signed-off-by: Jitao Shi <jitao.shi@mediatek.com>
+Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ .../devicetree/bindings/display/mediatek/mediatek,dpi.txt | 6 ++++++
+ 1 file changed, 6 insertions(+)
+
+diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.txt b/Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.txt
+index b6a7e7397b8b..b944fe067188 100644
+--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.txt
++++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.txt
+@@ -16,6 +16,9 @@ Required properties:
+ Documentation/devicetree/bindings/graph.txt. This port should be connected
+ to the input port of an attached HDMI or LVDS encoder chip.
+
++Optional properties:
++- pinctrl-names: Contain "default" and "sleep".
++
+ Example:
+
+ dpi0: dpi@1401d000 {
+@@ -26,6 +29,9 @@ dpi0: dpi@1401d000 {
+ <&mmsys CLK_MM_DPI_ENGINE>,
+ <&apmixedsys CLK_APMIXED_TVDPLL>;
+ clock-names = "pixel", "engine", "pll";
++ pinctrl-names = "default", "sleep";
++ pinctrl-0 = <&dpi_pin_func>;
++ pinctrl-1 = <&dpi_pin_idle>;
+
+ port {
+ dpi0_out: endpoint {
+--
+2.25.1
+
--- /dev/null
+From a61f6b883ea7018305ab13a2e4887c8529f3a9cc Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 19 Feb 2020 22:23:02 -0800
+Subject: e1000: Distribute switch variables for initialization
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Kees Cook <keescook@chromium.org>
+
+[ Upstream commit a34c7f5156654ebaf7eaace102938be7ff7036cb ]
+
+Variables declared in a switch statement before any case statements
+cannot be automatically initialized with compiler instrumentation (as
+they are not part of any execution flow). With GCC's proposed automatic
+stack variable initialization feature, this triggers a warning (and they
+don't get initialized). Clang's automatic stack variable initialization
+(via CONFIG_INIT_STACK_ALL=y) doesn't throw a warning, but it also
+doesn't initialize such variables[1]. Note that these warnings (or silent
+skipping) happen before the dead-store elimination optimization phase,
+so even when the automatic initializations are later elided in favor of
+direct initializations, the warnings remain.
+
+To avoid these problems, move such variables into the "case" where
+they're used or lift them up into the main function body.
+
+drivers/net/ethernet/intel/e1000/e1000_main.c: In function ‘e1000_xmit_frame’:
+drivers/net/ethernet/intel/e1000/e1000_main.c:3143:18: warning: statement will never be executed [-Wswitch-unreachable]
+ 3143 | unsigned int pull_size;
+ | ^~~~~~~~~
+
+[1] https://bugs.llvm.org/show_bug.cgi?id=44916
+
+Signed-off-by: Kees Cook <keescook@chromium.org>
+Tested-by: Aaron Brown <aaron.f.brown@intel.com>
+Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/ethernet/intel/e1000/e1000_main.c | 4 +++-
+ 1 file changed, 3 insertions(+), 1 deletion(-)
+
+diff --git a/drivers/net/ethernet/intel/e1000/e1000_main.c b/drivers/net/ethernet/intel/e1000/e1000_main.c
+index 3dd4aeb2706d..175681aa5260 100644
+--- a/drivers/net/ethernet/intel/e1000/e1000_main.c
++++ b/drivers/net/ethernet/intel/e1000/e1000_main.c
+@@ -3169,8 +3169,9 @@ static netdev_tx_t e1000_xmit_frame(struct sk_buff *skb,
+ hdr_len = skb_transport_offset(skb) + tcp_hdrlen(skb);
+ if (skb->data_len && hdr_len == len) {
+ switch (hw->mac_type) {
++ case e1000_82544: {
+ unsigned int pull_size;
+- case e1000_82544:
++
+ /* Make sure we have room to chop off 4 bytes,
+ * and that the end alignment will work out to
+ * this hardware's requirements
+@@ -3191,6 +3192,7 @@ static netdev_tx_t e1000_xmit_frame(struct sk_buff *skb,
+ }
+ len = skb_headlen(skb);
+ break;
++ }
+ default:
+ /* do nothing */
+ break;
+--
+2.25.1
+
--- /dev/null
+From 87b03b546697a94edd18adcbc6bc3694f140af09 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 5 Mar 2020 23:06:57 +0100
+Subject: exit: Move preemption fixup up, move blocking operations down
+
+From: Jann Horn <jannh@google.com>
+
+[ Upstream commit 586b58cac8b4683eb58a1446fbc399de18974e40 ]
+
+With CONFIG_DEBUG_ATOMIC_SLEEP=y and CONFIG_CGROUPS=y, kernel oopses in
+non-preemptible context look untidy; after the main oops, the kernel prints
+a "sleeping function called from invalid context" report because
+exit_signals() -> cgroup_threadgroup_change_begin() -> percpu_down_read()
+can sleep, and that happens before the preempt_count_set(PREEMPT_ENABLED)
+fixup.
+
+It looks like the same thing applies to profile_task_exit() and
+kcov_task_exit().
+
+Fix it by moving the preemption fixup up and the calls to
+profile_task_exit() and kcov_task_exit() down.
+
+Fixes: 1dc0fffc48af ("sched/core: Robustify preemption leak checks")
+Signed-off-by: Jann Horn <jannh@google.com>
+Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
+Link: https://lkml.kernel.org/r/20200305220657.46800-1-jannh@google.com
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ kernel/exit.c | 25 ++++++++++++++++---------
+ 1 file changed, 16 insertions(+), 9 deletions(-)
+
+diff --git a/kernel/exit.c b/kernel/exit.c
+index 7bee1dd596fa..7a7984d7a4d8 100644
+--- a/kernel/exit.c
++++ b/kernel/exit.c
+@@ -770,8 +770,12 @@ void __noreturn do_exit(long code)
+ struct task_struct *tsk = current;
+ int group_dead;
+
+- profile_task_exit(tsk);
+- kcov_task_exit(tsk);
++ /*
++ * We can get here from a kernel oops, sometimes with preemption off.
++ * Start by checking for critical errors.
++ * Then fix up important state like USER_DS and preemption.
++ * Then do everything else.
++ */
+
+ WARN_ON(blk_needs_flush_plug(tsk));
+
+@@ -789,6 +793,16 @@ void __noreturn do_exit(long code)
+ */
+ set_fs(USER_DS);
+
++ if (unlikely(in_atomic())) {
++ pr_info("note: %s[%d] exited with preempt_count %d\n",
++ current->comm, task_pid_nr(current),
++ preempt_count());
++ preempt_count_set(PREEMPT_ENABLED);
++ }
++
++ profile_task_exit(tsk);
++ kcov_task_exit(tsk);
++
+ ptrace_event(PTRACE_EVENT_EXIT, code);
+
+ validate_creds_for_do_exit(tsk);
+@@ -806,13 +820,6 @@ void __noreturn do_exit(long code)
+
+ exit_signals(tsk); /* sets PF_EXITING */
+
+- if (unlikely(in_atomic())) {
+- pr_info("note: %s[%d] exited with preempt_count %d\n",
+- current->comm, task_pid_nr(current),
+- preempt_count());
+- preempt_count_set(PREEMPT_ENABLED);
+- }
+-
+ /* sync mm's RSS info before statistics gathering */
+ if (tsk->mm)
+ sync_mm_rss(tsk->mm);
+--
+2.25.1
+
--- /dev/null
+From ae4991b96016a311a4140cc0c5a488f192570ce0 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 5 May 2020 10:45:21 +0800
+Subject: ixgbe: fix signed-integer-overflow warning
+
+From: Xie XiuQi <xiexiuqi@huawei.com>
+
+[ Upstream commit 3b70683fc4d68f5d915d9dc7e5ba72c732c7315c ]
+
+ubsan report this warning, fix it by adding a unsigned suffix.
+
+UBSAN: signed-integer-overflow in
+drivers/net/ethernet/intel/ixgbe/ixgbe_common.c:2246:26
+65535 * 65537 cannot be represented in type 'int'
+CPU: 21 PID: 7 Comm: kworker/u256:0 Not tainted 5.7.0-rc3-debug+ #39
+Hardware name: Huawei TaiShan 2280 V2/BC82AMDC, BIOS 2280-V2 03/27/2020
+Workqueue: ixgbe ixgbe_service_task [ixgbe]
+Call trace:
+ dump_backtrace+0x0/0x3f0
+ show_stack+0x28/0x38
+ dump_stack+0x154/0x1e4
+ ubsan_epilogue+0x18/0x60
+ handle_overflow+0xf8/0x148
+ __ubsan_handle_mul_overflow+0x34/0x48
+ ixgbe_fc_enable_generic+0x4d0/0x590 [ixgbe]
+ ixgbe_service_task+0xc20/0x1f78 [ixgbe]
+ process_one_work+0x8f0/0xf18
+ worker_thread+0x430/0x6d0
+ kthread+0x218/0x238
+ ret_from_fork+0x10/0x18
+
+Reported-by: Hulk Robot <hulkci@huawei.com>
+Signed-off-by: Xie XiuQi <xiexiuqi@huawei.com>
+Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
+Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/ethernet/intel/ixgbe/ixgbe_common.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_common.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_common.c
+index 815284fe9324..6b5662674c75 100644
+--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_common.c
++++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_common.c
+@@ -2267,7 +2267,7 @@ s32 ixgbe_fc_enable_generic(struct ixgbe_hw *hw)
+ }
+
+ /* Configure pause time (2 TCs per register) */
+- reg = hw->fc.pause_time * 0x00010001;
++ reg = hw->fc.pause_time * 0x00010001U;
+ for (i = 0; i < (MAX_TRAFFIC_CLASS / 2); i++)
+ IXGBE_WRITE_REG(hw, IXGBE_FCTTV(i), reg);
+
+--
+2.25.1
+
--- /dev/null
+From 74c03ff2d40e9985045c39993f8fc36f35843df5 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 14 May 2020 12:50:49 +0200
+Subject: ixgbe: Fix XDP redirect on archs with PAGE_SIZE above 4K
+
+From: Jesper Dangaard Brouer <brouer@redhat.com>
+
+[ Upstream commit 88eb0ee17b2ece64fcf6689a4557a5c2e7a89c4b ]
+
+The ixgbe driver have another memory model when compiled on archs with
+PAGE_SIZE above 4096 bytes. In this mode it doesn't split the page in
+two halves, but instead increment rx_buffer->page_offset by truesize of
+packet (which include headroom and tailroom for skb_shared_info).
+
+This is done correctly in ixgbe_build_skb(), but in ixgbe_rx_buffer_flip
+which is currently only called on XDP_TX and XDP_REDIRECT, it forgets
+to add the tailroom for skb_shared_info. This breaks XDP_REDIRECT, for
+veth and cpumap. Fix by adding size of skb_shared_info tailroom.
+
+Maintainers notice: This fix have been queued to Jeff.
+
+Fixes: 6453073987ba ("ixgbe: add initial support for xdp redirect")
+Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com>
+Signed-off-by: Alexei Starovoitov <ast@kernel.org>
+Cc: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
+Link: https://lore.kernel.org/bpf/158945344946.97035.17031588499266605743.stgit@firesoul
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
+index ba184287e11f..64ee45b6680a 100644
+--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
++++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
+@@ -2274,7 +2274,8 @@ static void ixgbe_rx_buffer_flip(struct ixgbe_ring *rx_ring,
+ rx_buffer->page_offset ^= truesize;
+ #else
+ unsigned int truesize = ring_uses_build_skb(rx_ring) ?
+- SKB_DATA_ALIGN(IXGBE_SKB_PAD + size) :
++ SKB_DATA_ALIGN(IXGBE_SKB_PAD + size) +
++ SKB_DATA_ALIGN(sizeof(struct skb_shared_info)) :
+ SKB_DATA_ALIGN(size);
+
+ rx_buffer->page_offset += truesize;
+--
+2.25.1
+
--- /dev/null
+From 49e26c6007a3d02516b0e053f105aba03bd7c619 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 6 May 2020 17:42:23 +0100
+Subject: kgdb: Fix spurious true from in_dbg_master()
+
+From: Daniel Thompson <daniel.thompson@linaro.org>
+
+[ Upstream commit 3fec4aecb311995189217e64d725cfe84a568de3 ]
+
+Currently there is a small window where a badly timed migration could
+cause in_dbg_master() to spuriously return true. Specifically if we
+migrate to a new core after reading the processor id and the previous
+core takes a breakpoint then we will evaluate true if we read
+kgdb_active before we get the IPI to bring us to halt.
+
+Fix this by checking irqs_disabled() first. Interrupts are always
+disabled when we are executing the kgdb trap so this is an acceptable
+prerequisite. This also allows us to replace raw_smp_processor_id()
+with smp_processor_id() since the short circuit logic will prevent
+warnings from PREEMPT_DEBUG.
+
+Fixes: dcc7871128e9 ("kgdb: core changes to support kdb")
+Suggested-by: Will Deacon <will@kernel.org>
+Link: https://lore.kernel.org/r/20200506164223.2875760-1-daniel.thompson@linaro.org
+Reviewed-by: Douglas Anderson <dianders@chromium.org>
+Signed-off-by: Daniel Thompson <daniel.thompson@linaro.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ include/linux/kgdb.h | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/include/linux/kgdb.h b/include/linux/kgdb.h
+index e465bb15912d..6be5545d3584 100644
+--- a/include/linux/kgdb.h
++++ b/include/linux/kgdb.h
+@@ -317,7 +317,7 @@ extern void gdbstub_exit(int status);
+ extern int kgdb_single_step;
+ extern atomic_t kgdb_active;
+ #define in_dbg_master() \
+- (raw_smp_processor_id() == atomic_read(&kgdb_active))
++ (irqs_disabled() && (smp_processor_id() == atomic_read(&kgdb_active)))
+ extern bool dbg_is_early;
+ extern void __init dbg_late_init(void);
+ #else /* ! CONFIG_KGDB */
+--
+2.25.1
+
--- /dev/null
+From 441b66292d0597820cd448e6934b41e2c30b09d4 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 7 May 2020 13:08:44 -0700
+Subject: kgdb: Prevent infinite recursive entries to the debugger
+
+From: Douglas Anderson <dianders@chromium.org>
+
+[ Upstream commit 3ca676e4ca60d1834bb77535dafe24169cadacef ]
+
+If we detect that we recursively entered the debugger we should hack
+our I/O ops to NULL so that the panic() in the next line won't
+actually cause another recursion into the debugger. The first line of
+kgdb_panic() will check this and return.
+
+Signed-off-by: Douglas Anderson <dianders@chromium.org>
+Reviewed-by: Daniel Thompson <daniel.thompson@linaro.org>
+Link: https://lore.kernel.org/r/20200507130644.v4.6.I89de39f68736c9de610e6f241e68d8dbc44bc266@changeid
+Signed-off-by: Daniel Thompson <daniel.thompson@linaro.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ kernel/debug/debug_core.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/kernel/debug/debug_core.c b/kernel/debug/debug_core.c
+index 94aa9ae0007a..159a53ff2716 100644
+--- a/kernel/debug/debug_core.c
++++ b/kernel/debug/debug_core.c
+@@ -444,6 +444,7 @@ static int kgdb_reenter_check(struct kgdb_state *ks)
+
+ if (exception_level > 1) {
+ dump_stack();
++ kgdb_io_module_registered = false;
+ panic("Recursive entry to debugger");
+ }
+
+--
+2.25.1
+
--- /dev/null
+From 59abb84ac2644bcca2fd86e7a0275beb921c8cd1 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 21 Apr 2020 14:47:04 -0700
+Subject: lib/mpi: Fix 64-bit MIPS build with Clang
+
+From: Nathan Chancellor <natechancellor@gmail.com>
+
+[ Upstream commit 18f1ca46858eac22437819937ae44aa9a8f9f2fa ]
+
+When building 64r6_defconfig with CONFIG_MIPS32_O32 disabled and
+CONFIG_CRYPTO_RSA enabled:
+
+lib/mpi/generic_mpih-mul1.c:37:24: error: invalid use of a cast in a
+inline asm context requiring an l-value: remove the cast
+or build with -fheinous-gnu-extensions
+ umul_ppmm(prod_high, prod_low, s1_ptr[j], s2_limb);
+ ~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+lib/mpi/longlong.h:664:22: note: expanded from macro 'umul_ppmm'
+ : "=d" ((UDItype)(w0))
+ ~~~~~~~~~~^~~
+lib/mpi/generic_mpih-mul1.c:37:13: error: invalid use of a cast in a
+inline asm context requiring an l-value: remove the cast
+or build with -fheinous-gnu-extensions
+ umul_ppmm(prod_high, prod_low, s1_ptr[j], s2_limb);
+ ~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+lib/mpi/longlong.h:668:22: note: expanded from macro 'umul_ppmm'
+ : "=d" ((UDItype)(w1))
+ ~~~~~~~~~~^~~
+2 errors generated.
+
+This special case for umul_ppmm for MIPS64r6 was added in
+commit bbc25bee37d2b ("lib/mpi: Fix umul_ppmm() for MIPS64r6"), due to
+GCC being inefficient and emitting a __multi3 intrinsic.
+
+There is no such issue with clang; with this patch applied, I can build
+this configuration without any problems and there are no link errors
+like mentioned in the commit above (which I can still reproduce with
+GCC 9.3.0 when that commit is reverted). Only use this definition when
+GCC is being used.
+
+This really should have been caught by commit b0c091ae04f67 ("lib/mpi:
+Eliminate unused umul_ppmm definitions for MIPS") when I was messing
+around in this area but I was not testing 64-bit MIPS at the time.
+
+Link: https://github.com/ClangBuiltLinux/linux/issues/885
+Reported-by: Dmitry Golovin <dima@golovin.in>
+Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
+Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ lib/mpi/longlong.h | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/lib/mpi/longlong.h b/lib/mpi/longlong.h
+index e01b705556aa..6c5229f98c9e 100644
+--- a/lib/mpi/longlong.h
++++ b/lib/mpi/longlong.h
+@@ -671,7 +671,7 @@ do { \
+ ************** MIPS/64 **************
+ ***************************************/
+ #if (defined(__mips) && __mips >= 3) && W_TYPE_SIZE == 64
+-#if defined(__mips_isa_rev) && __mips_isa_rev >= 6
++#if defined(__mips_isa_rev) && __mips_isa_rev >= 6 && defined(CONFIG_CC_IS_GCC)
+ /*
+ * GCC ends up emitting a __multi3 intrinsic call for MIPS64r6 with the plain C
+ * code below, so we special case MIPS64r6 until the compiler can do better.
+--
+2.25.1
+
--- /dev/null
+From 06599951d1c6c3998b600585ee35c0edc3bc9131 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 20 May 2020 14:32:02 +1000
+Subject: m68k: mac: Don't call via_flush_cache() on Mac IIfx
+
+From: Finn Thain <fthain@telegraphics.com.au>
+
+[ Upstream commit bcc44f6b74106b31f0b0408b70305a40360d63b7 ]
+
+There is no VIA2 chip on the Mac IIfx, so don't call via_flush_cache().
+This avoids a boot crash which appeared in v5.4.
+
+printk: console [ttyS0] enabled
+printk: bootconsole [debug0] disabled
+printk: bootconsole [debug0] disabled
+Calibrating delay loop... 9.61 BogoMIPS (lpj=48064)
+pid_max: default: 32768 minimum: 301
+Mount-cache hash table entries: 1024 (order: 0, 4096 bytes, linear)
+Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes, linear)
+devtmpfs: initialized
+random: get_random_u32 called from bucket_table_alloc.isra.27+0x68/0x194 with crng_init=0
+clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604462750000 ns
+futex hash table entries: 256 (order: -1, 3072 bytes, linear)
+NET: Registered protocol family 16
+Data read fault at 0x00000000 in Super Data (pc=0x8a6a)
+BAD KERNEL BUSERR
+Oops: 00000000
+Modules linked in:
+PC: [<00008a6a>] via_flush_cache+0x12/0x2c
+SR: 2700 SP: 01c1fe3c a2: 01c24000
+d0: 00001119 d1: 0000000c d2: 00012000 d3: 0000000f
+d4: 01c06840 d5: 00033b92 a0: 00000000 a1: 00000000
+Process swapper (pid: 1, task=01c24000)
+Frame format=B ssw=0755 isc=0200 isb=fff7 daddr=00000000 dobuf=01c1fed0
+baddr=00008a6e dibuf=0000004e ver=f
+Stack from 01c1fec4:
+ 01c1fed0 00007d7e 00010080 01c1fedc 0000792e 00000001 01c1fef4 00006b40
+ 01c80000 00040000 00000006 00000003 01c1ff1c 004a545e 004ff200 00040000
+ 00000000 00000003 01c06840 00033b92 004a5410 004b6c88 01c1ff84 000021e2
+ 00000073 00000003 01c06840 00033b92 0038507a 004bb094 004b6ca8 004b6c88
+ 004b6ca4 004b6c88 000021ae 00020002 00000000 01c0685d 00000000 01c1ffb4
+ 0049f938 00409c85 01c06840 0045bd40 00000073 00000002 00000002 00000000
+Call Trace: [<00007d7e>] mac_cache_card_flush+0x12/0x1c
+ [<00010080>] fix_dnrm+0x2/0x18
+ [<0000792e>] cache_push+0x46/0x5a
+ [<00006b40>] arch_dma_prep_coherent+0x60/0x6e
+ [<00040000>] switched_to_dl+0x76/0xd0
+ [<004a545e>] dma_atomic_pool_init+0x4e/0x188
+ [<00040000>] switched_to_dl+0x76/0xd0
+ [<00033b92>] parse_args+0x0/0x370
+ [<004a5410>] dma_atomic_pool_init+0x0/0x188
+ [<000021e2>] do_one_initcall+0x34/0x1be
+ [<00033b92>] parse_args+0x0/0x370
+ [<0038507a>] strcpy+0x0/0x1e
+ [<000021ae>] do_one_initcall+0x0/0x1be
+ [<00020002>] do_proc_dointvec_conv+0x54/0x74
+ [<0049f938>] kernel_init_freeable+0x126/0x190
+ [<0049f94c>] kernel_init_freeable+0x13a/0x190
+ [<004a5410>] dma_atomic_pool_init+0x0/0x188
+ [<00041798>] complete+0x0/0x3c
+ [<000b9b0c>] kfree+0x0/0x20a
+ [<0038df98>] schedule+0x0/0xd0
+ [<0038d604>] kernel_init+0x0/0xda
+ [<0038d610>] kernel_init+0xc/0xda
+ [<0038d604>] kernel_init+0x0/0xda
+ [<00002d38>] ret_from_kernel_thread+0xc/0x14
+Code: 0000 2079 0048 10da 2279 0048 10c8 d3c8 <1011> 0200 fff7 1280 d1f9 0048 10c8 1010 0000 0008 1080 4e5e 4e75 4e56 0000 2039
+Disabling lock debugging due to kernel taint
+Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
+
+Thanks to Stan Johnson for capturing the console log and running git
+bisect.
+
+Git bisect said commit 8e3a68fb55e0 ("dma-mapping: make
+dma_atomic_pool_init self-contained") is the first "bad" commit. I don't
+know why. Perhaps mach_l2_flush first became reachable with that commit.
+
+Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
+Reported-and-tested-by: Stan Johnson <userm57@yahoo.com>
+Signed-off-by: Finn Thain <fthain@telegraphics.com.au>
+Cc: Joshua Thompson <funaho@jurai.org>
+Link: https://lore.kernel.org/r/b8bbeef197d6b3898e82ed0d231ad08f575a4b34.1589949122.git.fthain@telegraphics.com.au
+Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ arch/m68k/include/asm/mac_via.h | 1 +
+ arch/m68k/mac/config.c | 21 ++-------------------
+ arch/m68k/mac/via.c | 6 +++++-
+ 3 files changed, 8 insertions(+), 20 deletions(-)
+
+diff --git a/arch/m68k/include/asm/mac_via.h b/arch/m68k/include/asm/mac_via.h
+index de1470c4d829..1149251ea58d 100644
+--- a/arch/m68k/include/asm/mac_via.h
++++ b/arch/m68k/include/asm/mac_via.h
+@@ -257,6 +257,7 @@ extern int rbv_present,via_alt_mapping;
+
+ struct irq_desc;
+
++extern void via_l2_flush(int writeback);
+ extern void via_register_interrupts(void);
+ extern void via_irq_enable(int);
+ extern void via_irq_disable(int);
+diff --git a/arch/m68k/mac/config.c b/arch/m68k/mac/config.c
+index 2004b3f72d80..3ea7450c51f2 100644
+--- a/arch/m68k/mac/config.c
++++ b/arch/m68k/mac/config.c
+@@ -61,7 +61,6 @@ extern void iop_preinit(void);
+ extern void iop_init(void);
+ extern void via_init(void);
+ extern void via_init_clock(irq_handler_t func);
+-extern void via_flush_cache(void);
+ extern void oss_init(void);
+ extern void psc_init(void);
+ extern void baboon_init(void);
+@@ -132,21 +131,6 @@ int __init mac_parse_bootinfo(const struct bi_record *record)
+ return unknown;
+ }
+
+-/*
+- * Flip into 24bit mode for an instant - flushes the L2 cache card. We
+- * have to disable interrupts for this. Our IRQ handlers will crap
+- * themselves if they take an IRQ in 24bit mode!
+- */
+-
+-static void mac_cache_card_flush(int writeback)
+-{
+- unsigned long flags;
+-
+- local_irq_save(flags);
+- via_flush_cache();
+- local_irq_restore(flags);
+-}
+-
+ void __init config_mac(void)
+ {
+ if (!MACH_IS_MAC)
+@@ -179,9 +163,8 @@ void __init config_mac(void)
+ * not.
+ */
+
+- if (macintosh_config->ident == MAC_MODEL_IICI
+- || macintosh_config->ident == MAC_MODEL_IIFX)
+- mach_l2_flush = mac_cache_card_flush;
++ if (macintosh_config->ident == MAC_MODEL_IICI)
++ mach_l2_flush = via_l2_flush;
+ }
+
+
+diff --git a/arch/m68k/mac/via.c b/arch/m68k/mac/via.c
+index 863806e6775a..6ab6a1d54b37 100644
+--- a/arch/m68k/mac/via.c
++++ b/arch/m68k/mac/via.c
+@@ -300,10 +300,14 @@ void via_debug_dump(void)
+ * the system into 24-bit mode for an instant.
+ */
+
+-void via_flush_cache(void)
++void via_l2_flush(int writeback)
+ {
++ unsigned long flags;
++
++ local_irq_save(flags);
+ via2[gBufB] &= ~VIA2B_vMode32;
+ via2[gBufB] |= VIA2B_vMode32;
++ local_irq_restore(flags);
+ }
+
+ /*
+--
+2.25.1
+
--- /dev/null
+From 35c8dd709c0848aeff4a47af86293ff4a1bedf15 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 26 May 2020 14:27:51 +0200
+Subject: macvlan: Skip loopback packets in RX handler
+
+From: Alexander Sverdlin <alexander.sverdlin@nokia.com>
+
+[ Upstream commit 81f3dc9349ce0bf7b8447f147f45e70f0a5b36a6 ]
+
+Ignore loopback-originatig packets soon enough and don't try to process L2
+header where it doesn't exist. The very similar br_handle_frame() in bridge
+code performs exactly the same check.
+
+This is an example of such ICMPv6 packet:
+
+skb len=96 headroom=40 headlen=96 tailroom=56
+mac=(40,0) net=(40,40) trans=80
+shinfo(txflags=0 nr_frags=0 gso(size=0 type=0 segs=0))
+csum(0xae2e9a2f ip_summed=1 complete_sw=0 valid=0 level=0)
+hash(0xc97ebd88 sw=1 l4=1) proto=0x86dd pkttype=5 iif=24
+dev name=etha01.212 feat=0x0x0000000040005000
+skb headroom: 00000000: 00 7c 86 52 84 88 ff ff 00 00 00 00 00 00 08 00
+skb headroom: 00000010: 45 00 00 9e 5d 5c 40 00 40 11 33 33 00 00 00 01
+skb headroom: 00000020: 02 40 43 80 00 00 86 dd
+skb linear: 00000000: 60 09 88 bd 00 38 3a ff fe 80 00 00 00 00 00 00
+skb linear: 00000010: 00 40 43 ff fe 80 00 00 ff 02 00 00 00 00 00 00
+skb linear: 00000020: 00 00 00 00 00 00 00 01 86 00 61 00 40 00 00 2d
+skb linear: 00000030: 00 00 00 00 00 00 00 00 03 04 40 e0 00 00 01 2c
+skb linear: 00000040: 00 00 00 78 00 00 00 00 fd 5f 42 68 23 87 a8 81
+skb linear: 00000050: 00 00 00 00 00 00 00 00 01 01 02 40 43 80 00 00
+skb tailroom: 00000000: ...
+skb tailroom: 00000010: ...
+skb tailroom: 00000020: ...
+skb tailroom: 00000030: ...
+
+Call Trace, how it happens exactly:
+ ...
+ macvlan_handle_frame+0x321/0x425 [macvlan]
+ ? macvlan_forward_source+0x110/0x110 [macvlan]
+ __netif_receive_skb_core+0x545/0xda0
+ ? enqueue_task_fair+0xe5/0x8e0
+ ? __netif_receive_skb_one_core+0x36/0x70
+ __netif_receive_skb_one_core+0x36/0x70
+ process_backlog+0x97/0x140
+ net_rx_action+0x1eb/0x350
+ ? __hrtimer_run_queues+0x136/0x2e0
+ __do_softirq+0xe3/0x383
+ do_softirq_own_stack+0x2a/0x40
+ </IRQ>
+ do_softirq.part.4+0x4e/0x50
+ netif_rx_ni+0x60/0xd0
+ dev_loopback_xmit+0x83/0xf0
+ ip6_finish_output2+0x575/0x590 [ipv6]
+ ? ip6_cork_release.isra.1+0x64/0x90 [ipv6]
+ ? __ip6_make_skb+0x38d/0x680 [ipv6]
+ ? ip6_output+0x6c/0x140 [ipv6]
+ ip6_output+0x6c/0x140 [ipv6]
+ ip6_send_skb+0x1e/0x60 [ipv6]
+ rawv6_sendmsg+0xc4b/0xe10 [ipv6]
+ ? proc_put_long+0xd0/0xd0
+ ? rw_copy_check_uvector+0x4e/0x110
+ ? sock_sendmsg+0x36/0x40
+ sock_sendmsg+0x36/0x40
+ ___sys_sendmsg+0x2b6/0x2d0
+ ? proc_dointvec+0x23/0x30
+ ? addrconf_sysctl_forward+0x8d/0x250 [ipv6]
+ ? dev_forward_change+0x130/0x130 [ipv6]
+ ? _raw_spin_unlock+0x12/0x30
+ ? proc_sys_call_handler.isra.14+0x9f/0x110
+ ? __call_rcu+0x213/0x510
+ ? get_max_files+0x10/0x10
+ ? trace_hardirqs_on+0x2c/0xe0
+ ? __sys_sendmsg+0x63/0xa0
+ __sys_sendmsg+0x63/0xa0
+ do_syscall_64+0x6c/0x1e0
+ entry_SYSCALL_64_after_hwframe+0x49/0xbe
+
+Signed-off-by: Alexander Sverdlin <alexander.sverdlin@nokia.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/macvlan.c | 4 ++++
+ 1 file changed, 4 insertions(+)
+
+diff --git a/drivers/net/macvlan.c b/drivers/net/macvlan.c
+index 3072fc902eca..b7f41c52766f 100644
+--- a/drivers/net/macvlan.c
++++ b/drivers/net/macvlan.c
+@@ -449,6 +449,10 @@ static rx_handler_result_t macvlan_handle_frame(struct sk_buff **pskb)
+ int ret;
+ rx_handler_result_t handle_res;
+
++ /* Packets from dev_loopback_xmit() do not have L2 header, bail out */
++ if (unlikely(skb->pkt_type == PACKET_LOOPBACK))
++ return RX_HANDLER_PASS;
++
+ port = macvlan_port_get_rcu(skb->dev);
+ if (is_multicast_ether_addr(eth->h_dest)) {
+ unsigned int hash;
+--
+2.25.1
+
--- /dev/null
+From 359e2bb07a531cf6eb026bd7b0ee372b34000dd7 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Sat, 4 Apr 2020 23:57:09 +0200
+Subject: md: don't flush workqueue unconditionally in md_open
+
+From: Guoqing Jiang <guoqing.jiang@cloud.ionos.com>
+
+[ Upstream commit f6766ff6afff70e2aaf39e1511e16d471de7c3ae ]
+
+We need to check mddev->del_work before flush workqueu since the purpose
+of flush is to ensure the previous md is disappeared. Otherwise the similar
+deadlock appeared if LOCKDEP is enabled, it is due to md_open holds the
+bdev->bd_mutex before flush workqueue.
+
+kernel: [ 154.522645] ======================================================
+kernel: [ 154.522647] WARNING: possible circular locking dependency detected
+kernel: [ 154.522650] 5.6.0-rc7-lp151.27-default #25 Tainted: G O
+kernel: [ 154.522651] ------------------------------------------------------
+kernel: [ 154.522653] mdadm/2482 is trying to acquire lock:
+kernel: [ 154.522655] ffff888078529128 ((wq_completion)md_misc){+.+.}, at: flush_workqueue+0x84/0x4b0
+kernel: [ 154.522673]
+kernel: [ 154.522673] but task is already holding lock:
+kernel: [ 154.522675] ffff88804efa9338 (&bdev->bd_mutex){+.+.}, at: __blkdev_get+0x79/0x590
+kernel: [ 154.522691]
+kernel: [ 154.522691] which lock already depends on the new lock.
+kernel: [ 154.522691]
+kernel: [ 154.522694]
+kernel: [ 154.522694] the existing dependency chain (in reverse order) is:
+kernel: [ 154.522696]
+kernel: [ 154.522696] -> #4 (&bdev->bd_mutex){+.+.}:
+kernel: [ 154.522704] __mutex_lock+0x87/0x950
+kernel: [ 154.522706] __blkdev_get+0x79/0x590
+kernel: [ 154.522708] blkdev_get+0x65/0x140
+kernel: [ 154.522709] blkdev_get_by_dev+0x2f/0x40
+kernel: [ 154.522716] lock_rdev+0x3d/0x90 [md_mod]
+kernel: [ 154.522719] md_import_device+0xd6/0x1b0 [md_mod]
+kernel: [ 154.522723] new_dev_store+0x15e/0x210 [md_mod]
+kernel: [ 154.522728] md_attr_store+0x7a/0xc0 [md_mod]
+kernel: [ 154.522732] kernfs_fop_write+0x117/0x1b0
+kernel: [ 154.522735] vfs_write+0xad/0x1a0
+kernel: [ 154.522737] ksys_write+0xa4/0xe0
+kernel: [ 154.522745] do_syscall_64+0x64/0x2b0
+kernel: [ 154.522748] entry_SYSCALL_64_after_hwframe+0x49/0xbe
+kernel: [ 154.522749]
+kernel: [ 154.522749] -> #3 (&mddev->reconfig_mutex){+.+.}:
+kernel: [ 154.522752] __mutex_lock+0x87/0x950
+kernel: [ 154.522756] new_dev_store+0xc9/0x210 [md_mod]
+kernel: [ 154.522759] md_attr_store+0x7a/0xc0 [md_mod]
+kernel: [ 154.522761] kernfs_fop_write+0x117/0x1b0
+kernel: [ 154.522763] vfs_write+0xad/0x1a0
+kernel: [ 154.522765] ksys_write+0xa4/0xe0
+kernel: [ 154.522767] do_syscall_64+0x64/0x2b0
+kernel: [ 154.522769] entry_SYSCALL_64_after_hwframe+0x49/0xbe
+kernel: [ 154.522770]
+kernel: [ 154.522770] -> #2 (kn->count#253){++++}:
+kernel: [ 154.522775] __kernfs_remove+0x253/0x2c0
+kernel: [ 154.522778] kernfs_remove+0x1f/0x30
+kernel: [ 154.522780] kobject_del+0x28/0x60
+kernel: [ 154.522783] mddev_delayed_delete+0x24/0x30 [md_mod]
+kernel: [ 154.522786] process_one_work+0x2a7/0x5f0
+kernel: [ 154.522788] worker_thread+0x2d/0x3d0
+kernel: [ 154.522793] kthread+0x117/0x130
+kernel: [ 154.522795] ret_from_fork+0x3a/0x50
+kernel: [ 154.522796]
+kernel: [ 154.522796] -> #1 ((work_completion)(&mddev->del_work)){+.+.}:
+kernel: [ 154.522800] process_one_work+0x27e/0x5f0
+kernel: [ 154.522802] worker_thread+0x2d/0x3d0
+kernel: [ 154.522804] kthread+0x117/0x130
+kernel: [ 154.522806] ret_from_fork+0x3a/0x50
+kernel: [ 154.522807]
+kernel: [ 154.522807] -> #0 ((wq_completion)md_misc){+.+.}:
+kernel: [ 154.522813] __lock_acquire+0x1392/0x1690
+kernel: [ 154.522816] lock_acquire+0xb4/0x1a0
+kernel: [ 154.522818] flush_workqueue+0xab/0x4b0
+kernel: [ 154.522821] md_open+0xb6/0xc0 [md_mod]
+kernel: [ 154.522823] __blkdev_get+0xea/0x590
+kernel: [ 154.522825] blkdev_get+0x65/0x140
+kernel: [ 154.522828] do_dentry_open+0x1d1/0x380
+kernel: [ 154.522831] path_openat+0x567/0xcc0
+kernel: [ 154.522834] do_filp_open+0x9b/0x110
+kernel: [ 154.522836] do_sys_openat2+0x201/0x2a0
+kernel: [ 154.522838] do_sys_open+0x57/0x80
+kernel: [ 154.522840] do_syscall_64+0x64/0x2b0
+kernel: [ 154.522842] entry_SYSCALL_64_after_hwframe+0x49/0xbe
+kernel: [ 154.522844]
+kernel: [ 154.522844] other info that might help us debug this:
+kernel: [ 154.522844]
+kernel: [ 154.522846] Chain exists of:
+kernel: [ 154.522846] (wq_completion)md_misc --> &mddev->reconfig_mutex --> &bdev->bd_mutex
+kernel: [ 154.522846]
+kernel: [ 154.522850] Possible unsafe locking scenario:
+kernel: [ 154.522850]
+kernel: [ 154.522852] CPU0 CPU1
+kernel: [ 154.522853] ---- ----
+kernel: [ 154.522854] lock(&bdev->bd_mutex);
+kernel: [ 154.522856] lock(&mddev->reconfig_mutex);
+kernel: [ 154.522858] lock(&bdev->bd_mutex);
+kernel: [ 154.522860] lock((wq_completion)md_misc);
+kernel: [ 154.522861]
+kernel: [ 154.522861] *** DEADLOCK ***
+kernel: [ 154.522861]
+kernel: [ 154.522864] 1 lock held by mdadm/2482:
+kernel: [ 154.522865] #0: ffff88804efa9338 (&bdev->bd_mutex){+.+.}, at: __blkdev_get+0x79/0x590
+kernel: [ 154.522868]
+kernel: [ 154.522868] stack backtrace:
+kernel: [ 154.522873] CPU: 1 PID: 2482 Comm: mdadm Tainted: G O 5.6.0-rc7-lp151.27-default #25
+kernel: [ 154.522875] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014
+kernel: [ 154.522878] Call Trace:
+kernel: [ 154.522881] dump_stack+0x8f/0xcb
+kernel: [ 154.522884] check_noncircular+0x194/0x1b0
+kernel: [ 154.522888] ? __lock_acquire+0x1392/0x1690
+kernel: [ 154.522890] __lock_acquire+0x1392/0x1690
+kernel: [ 154.522893] lock_acquire+0xb4/0x1a0
+kernel: [ 154.522895] ? flush_workqueue+0x84/0x4b0
+kernel: [ 154.522898] flush_workqueue+0xab/0x4b0
+kernel: [ 154.522900] ? flush_workqueue+0x84/0x4b0
+kernel: [ 154.522905] ? md_open+0xb6/0xc0 [md_mod]
+kernel: [ 154.522908] md_open+0xb6/0xc0 [md_mod]
+kernel: [ 154.522910] __blkdev_get+0xea/0x590
+kernel: [ 154.522912] ? bd_acquire+0xc0/0xc0
+kernel: [ 154.522914] blkdev_get+0x65/0x140
+kernel: [ 154.522916] ? bd_acquire+0xc0/0xc0
+kernel: [ 154.522918] do_dentry_open+0x1d1/0x380
+kernel: [ 154.522921] path_openat+0x567/0xcc0
+kernel: [ 154.522923] ? __lock_acquire+0x380/0x1690
+kernel: [ 154.522926] do_filp_open+0x9b/0x110
+kernel: [ 154.522929] ? __alloc_fd+0xe5/0x1f0
+kernel: [ 154.522935] ? kmem_cache_alloc+0x28c/0x630
+kernel: [ 154.522939] ? do_sys_openat2+0x201/0x2a0
+kernel: [ 154.522941] do_sys_openat2+0x201/0x2a0
+kernel: [ 154.522944] do_sys_open+0x57/0x80
+kernel: [ 154.522946] do_syscall_64+0x64/0x2b0
+kernel: [ 154.522948] entry_SYSCALL_64_after_hwframe+0x49/0xbe
+kernel: [ 154.522951] RIP: 0033:0x7f98d279d9ae
+
+And md_alloc also flushed the same workqueue, but the thing is different
+here. Because all the paths call md_alloc don't hold bdev->bd_mutex, and
+the flush is necessary to avoid race condition, so leave it as it is.
+
+Signed-off-by: Guoqing Jiang <guoqing.jiang@cloud.ionos.com>
+Signed-off-by: Song Liu <songliubraving@fb.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/md/md.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+diff --git a/drivers/md/md.c b/drivers/md/md.c
+index b942c74f1ce8..948344531baf 100644
+--- a/drivers/md/md.c
++++ b/drivers/md/md.c
+@@ -7411,7 +7411,8 @@ static int md_open(struct block_device *bdev, fmode_t mode)
+ */
+ mddev_put(mddev);
+ /* Wait until bdev->bd_disk is definitely gone */
+- flush_workqueue(md_misc_wq);
++ if (work_pending(&mddev->del_work))
++ flush_workqueue(md_misc_wq);
+ /* Then retry the open from the top */
+ return -ERESTARTSYS;
+ }
+--
+2.25.1
+
--- /dev/null
+From 716e864b7463ab01349a8d387ccba1d961cfa2a6 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 5 May 2020 10:25:56 +0200
+Subject: media: cec: silence shift wrapping warning in __cec_s_log_addrs()
+
+From: Dan Carpenter <dan.carpenter@oracle.com>
+
+[ Upstream commit 3b5af3171e2d5a73ae6f04965ed653d039904eb6 ]
+
+The log_addrs->log_addr_type[i] value is a u8 which is controlled by
+the user and comes from the ioctl. If it's over 31 then that results in
+undefined behavior (shift wrapping) and that leads to a Smatch static
+checker warning. We already cap the value later so we can silence the
+warning just by re-ordering the existing checks.
+
+I think the UBSan checker will also catch this bug at runtime and
+generate a warning. But otherwise the bug is harmless.
+
+Fixes: 9881fe0ca187 ("[media] cec: add HDMI CEC framework (adapter)")
+Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
+Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
+Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/media/cec/cec-adap.c | 8 ++++----
+ 1 file changed, 4 insertions(+), 4 deletions(-)
+
+diff --git a/drivers/media/cec/cec-adap.c b/drivers/media/cec/cec-adap.c
+index 0d7d687aeea0..061b7824f698 100644
+--- a/drivers/media/cec/cec-adap.c
++++ b/drivers/media/cec/cec-adap.c
+@@ -1624,6 +1624,10 @@ int __cec_s_log_addrs(struct cec_adapter *adap,
+ unsigned j;
+
+ log_addrs->log_addr[i] = CEC_LOG_ADDR_INVALID;
++ if (log_addrs->log_addr_type[i] > CEC_LOG_ADDR_TYPE_UNREGISTERED) {
++ dprintk(1, "unknown logical address type\n");
++ return -EINVAL;
++ }
+ if (type_mask & (1 << log_addrs->log_addr_type[i])) {
+ dprintk(1, "duplicate logical address type\n");
+ return -EINVAL;
+@@ -1644,10 +1648,6 @@ int __cec_s_log_addrs(struct cec_adapter *adap,
+ dprintk(1, "invalid primary device type\n");
+ return -EINVAL;
+ }
+- if (log_addrs->log_addr_type[i] > CEC_LOG_ADDR_TYPE_UNREGISTERED) {
+- dprintk(1, "unknown logical address type\n");
+- return -EINVAL;
+- }
+ for (j = 0; j < feature_sz; j++) {
+ if ((features[j] & 0x80) == 0) {
+ if (op_is_dev_features)
+--
+2.25.1
+
--- /dev/null
+From 13e102e1157a4b7fbba81d553f004d703e72f621 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Mon, 10 Feb 2020 18:51:33 +0100
+Subject: media: dvb: return -EREMOTEIO on i2c transfer failure.
+
+From: Colin Ian King <colin.king@canonical.com>
+
+[ Upstream commit 96f3a9392799dd0f6472648a7366622ffd0989f3 ]
+
+Currently when i2c transfers fail the error return -EREMOTEIO
+is assigned to err but then later overwritten when the tuner
+attach call is made. Fix this by returning early with the
+error return code -EREMOTEIO on i2c transfer failure errors.
+
+If the transfer fails, an uninitialized value will be read from b2.
+
+Addresses-Coverity: ("Unused value")
+
+Fixes: fbfee8684ff2 ("V4L/DVB (5651): Dibusb-mb: convert pll handling to properly use dvb-pll")
+Signed-off-by: Colin Ian King <colin.king@canonical.com>
+Signed-off-by: Sean Young <sean@mess.org>
+Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/media/usb/dvb-usb/dibusb-mb.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/drivers/media/usb/dvb-usb/dibusb-mb.c b/drivers/media/usb/dvb-usb/dibusb-mb.c
+index a0057641cc86..c55180912c3a 100644
+--- a/drivers/media/usb/dvb-usb/dibusb-mb.c
++++ b/drivers/media/usb/dvb-usb/dibusb-mb.c
+@@ -84,7 +84,7 @@ static int dibusb_tuner_probe_and_attach(struct dvb_usb_adapter *adap)
+
+ if (i2c_transfer(&adap->dev->i2c_adap, msg, 2) != 2) {
+ err("tuner i2c write failed.");
+- ret = -EREMOTEIO;
++ return -EREMOTEIO;
+ }
+
+ if (adap->fe_adap[0].fe->ops.i2c_gate_ctrl)
+--
+2.25.1
+
--- /dev/null
+From 6a4a596febb6a56f6a9d9af10f9b527fdb2dc994 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 7 Apr 2020 17:44:17 +0200
+Subject: media: platform: fcp: Set appropriate DMA parameters
+
+From: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
+
+[ Upstream commit dd844fb8e50b12e65bbdc5746c9876c6735500df ]
+
+Enabling CONFIG_DMA_API_DEBUG=y and CONFIG_DMA_API_DEBUG_SG=y will
+enable extra validation on DMA operations ensuring that the size
+restraints are met.
+
+When using the FCP in conjunction with the VSP1/DU, and display frames,
+the size of the DMA operations is larger than the default maximum
+segment size reported by the DMA core (64K). With the DMA debug enabled,
+this produces a warning such as the following:
+
+"DMA-API: rcar-fcp fea27000.fcp: mapping sg segment longer than device
+claims to support [len=3145728] [max=65536]"
+
+We have no specific limitation on the segment size which isn't already
+handled by the VSP1/DU which actually handles the DMA allcoations and
+buffer management, so define a maximum segment size of up to 4GB (a 32
+bit mask).
+
+Reported-by: Geert Uytterhoeven <geert+renesas@glider.be>
+Fixes: 7b49235e83b2 ("[media] v4l: Add Renesas R-Car FCP driver")
+Signed-off-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
+Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
+Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
+Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
+Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/media/platform/rcar-fcp.c | 5 +++++
+ 1 file changed, 5 insertions(+)
+
+diff --git a/drivers/media/platform/rcar-fcp.c b/drivers/media/platform/rcar-fcp.c
+index 2988031d285d..0047d144c932 100644
+--- a/drivers/media/platform/rcar-fcp.c
++++ b/drivers/media/platform/rcar-fcp.c
+@@ -12,6 +12,7 @@
+ */
+
+ #include <linux/device.h>
++#include <linux/dma-mapping.h>
+ #include <linux/list.h>
+ #include <linux/module.h>
+ #include <linux/mutex.h>
+@@ -24,6 +25,7 @@
+ struct rcar_fcp_device {
+ struct list_head list;
+ struct device *dev;
++ struct device_dma_parameters dma_parms;
+ };
+
+ static LIST_HEAD(fcp_devices);
+@@ -139,6 +141,9 @@ static int rcar_fcp_probe(struct platform_device *pdev)
+
+ fcp->dev = &pdev->dev;
+
++ fcp->dev->dma_parms = &fcp->dma_parms;
++ dma_set_max_seg_size(fcp->dev, DMA_BIT_MASK(32));
++
+ pm_runtime_enable(&pdev->dev);
+
+ mutex_lock(&fcp_lock);
+--
+2.25.1
+
--- /dev/null
+From efbd3080da4370a98a91e49e693bed9fa0a27b55 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 14 Nov 2019 21:03:57 +0100
+Subject: media: si2157: Better check for running tuner in init
+
+From: Brad Love <brad@nextdimension.cc>
+
+[ Upstream commit e955f959ac52e145f27ff2be9078b646d0352af0 ]
+
+Getting the Xtal trim property to check if running is less error prone.
+Reset if_frequency if state is unknown.
+
+Replaces the previous "garbage check".
+
+Signed-off-by: Brad Love <brad@nextdimension.cc>
+Signed-off-by: Sean Young <sean@mess.org>
+Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/media/tuners/si2157.c | 15 +++++++--------
+ 1 file changed, 7 insertions(+), 8 deletions(-)
+
+diff --git a/drivers/media/tuners/si2157.c b/drivers/media/tuners/si2157.c
+index e35b1faf0ddc..c826997f5433 100644
+--- a/drivers/media/tuners/si2157.c
++++ b/drivers/media/tuners/si2157.c
+@@ -84,24 +84,23 @@ static int si2157_init(struct dvb_frontend *fe)
+ struct si2157_cmd cmd;
+ const struct firmware *fw;
+ const char *fw_name;
+- unsigned int uitmp, chip_id;
++ unsigned int chip_id, xtal_trim;
+
+ dev_dbg(&client->dev, "\n");
+
+- /* Returned IF frequency is garbage when firmware is not running */
+- memcpy(cmd.args, "\x15\x00\x06\x07", 4);
++ /* Try to get Xtal trim property, to verify tuner still running */
++ memcpy(cmd.args, "\x15\x00\x04\x02", 4);
+ cmd.wlen = 4;
+ cmd.rlen = 4;
+ ret = si2157_cmd_execute(client, &cmd);
+- if (ret)
+- goto err;
+
+- uitmp = cmd.args[2] << 0 | cmd.args[3] << 8;
+- dev_dbg(&client->dev, "if_frequency kHz=%u\n", uitmp);
++ xtal_trim = cmd.args[2] | (cmd.args[3] << 8);
+
+- if (uitmp == dev->if_frequency / 1000)
++ if (ret == 0 && xtal_trim < 16)
+ goto warm;
+
++ dev->if_frequency = 0; /* we no longer know current tuner state */
++
+ /* power up */
+ if (dev->chiptype == SI2157_CHIPTYPE_SI2146) {
+ memcpy(cmd.args, "\xc0\x05\x01\x00\x00\x0b\x00\x00\x01", 9);
+--
+2.25.1
+
--- /dev/null
+From 350121baef03386ef97658470583dd41449c440a Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 21 May 2020 17:07:22 +0300
+Subject: mips: Add udelay lpj numbers adjustment
+
+From: Serge Semin <Sergey.Semin@baikalelectronics.ru>
+
+[ Upstream commit ed26aacfb5f71eecb20a51c4467da440cb719d66 ]
+
+Loops-per-jiffies is a special number which represents a number of
+noop-loop cycles per CPU-scheduler quantum - jiffies. As you
+understand aside from CPU-specific implementation it depends on
+the CPU frequency. So when a platform has the CPU frequency fixed,
+we have no problem and the current udelay interface will work
+just fine. But as soon as CPU-freq driver is enabled and the cores
+frequency changes, we'll end up with distorted udelay's. In order
+to fix this we have to accordinly adjust the per-CPU udelay_val
+(the same as the global loops_per_jiffy) number. This can be done
+in the CPU-freq transition event handler. We subscribe to that event
+in the MIPS arch time-inititalization method.
+
+Co-developed-by: Alexey Malahov <Alexey.Malahov@baikalelectronics.ru>
+Signed-off-by: Alexey Malahov <Alexey.Malahov@baikalelectronics.ru>
+Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
+Reviewed-by: Jiaxun Yang <jiaxun.yang@flygoat.com>
+Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
+Cc: Paul Burton <paulburton@kernel.org>
+Cc: Ralf Baechle <ralf@linux-mips.org>
+Cc: Arnd Bergmann <arnd@arndb.de>
+Cc: Rob Herring <robh+dt@kernel.org>
+Cc: devicetree@vger.kernel.org
+Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ arch/mips/kernel/time.c | 70 +++++++++++++++++++++++++++++++++++++++++
+ 1 file changed, 70 insertions(+)
+
+diff --git a/arch/mips/kernel/time.c b/arch/mips/kernel/time.c
+index a6ebc8135112..df18f386d457 100644
+--- a/arch/mips/kernel/time.c
++++ b/arch/mips/kernel/time.c
+@@ -22,12 +22,82 @@
+ #include <linux/smp.h>
+ #include <linux/spinlock.h>
+ #include <linux/export.h>
++#include <linux/cpufreq.h>
++#include <linux/delay.h>
+
+ #include <asm/cpu-features.h>
+ #include <asm/cpu-type.h>
+ #include <asm/div64.h>
+ #include <asm/time.h>
+
++#ifdef CONFIG_CPU_FREQ
++
++static DEFINE_PER_CPU(unsigned long, pcp_lpj_ref);
++static DEFINE_PER_CPU(unsigned long, pcp_lpj_ref_freq);
++static unsigned long glb_lpj_ref;
++static unsigned long glb_lpj_ref_freq;
++
++static int cpufreq_callback(struct notifier_block *nb,
++ unsigned long val, void *data)
++{
++ struct cpufreq_freqs *freq = data;
++ struct cpumask *cpus = freq->policy->cpus;
++ unsigned long lpj;
++ int cpu;
++
++ /*
++ * Skip lpj numbers adjustment if the CPU-freq transition is safe for
++ * the loops delay. (Is this possible?)
++ */
++ if (freq->flags & CPUFREQ_CONST_LOOPS)
++ return NOTIFY_OK;
++
++ /* Save the initial values of the lpjes for future scaling. */
++ if (!glb_lpj_ref) {
++ glb_lpj_ref = boot_cpu_data.udelay_val;
++ glb_lpj_ref_freq = freq->old;
++
++ for_each_online_cpu(cpu) {
++ per_cpu(pcp_lpj_ref, cpu) =
++ cpu_data[cpu].udelay_val;
++ per_cpu(pcp_lpj_ref_freq, cpu) = freq->old;
++ }
++ }
++
++ /*
++ * Adjust global lpj variable and per-CPU udelay_val number in
++ * accordance with the new CPU frequency.
++ */
++ if ((val == CPUFREQ_PRECHANGE && freq->old < freq->new) ||
++ (val == CPUFREQ_POSTCHANGE && freq->old > freq->new)) {
++ loops_per_jiffy = cpufreq_scale(glb_lpj_ref,
++ glb_lpj_ref_freq,
++ freq->new);
++
++ for_each_cpu(cpu, cpus) {
++ lpj = cpufreq_scale(per_cpu(pcp_lpj_ref, cpu),
++ per_cpu(pcp_lpj_ref_freq, cpu),
++ freq->new);
++ cpu_data[cpu].udelay_val = (unsigned int)lpj;
++ }
++ }
++
++ return NOTIFY_OK;
++}
++
++static struct notifier_block cpufreq_notifier = {
++ .notifier_call = cpufreq_callback,
++};
++
++static int __init register_cpufreq_notifier(void)
++{
++ return cpufreq_register_notifier(&cpufreq_notifier,
++ CPUFREQ_TRANSITION_NOTIFIER);
++}
++core_initcall(register_cpufreq_notifier);
++
++#endif /* CONFIG_CPU_FREQ */
++
+ /*
+ * forward reference
+ */
+--
+2.25.1
+
--- /dev/null
+From f0c964cc5dd40bfeb79a5b03110716429754e5b5 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 6 May 2020 20:42:22 +0300
+Subject: mips: cm: Fix an invalid error code of INTVN_*_ERR
+
+From: Serge Semin <Sergey.Semin@baikalelectronics.ru>
+
+[ Upstream commit 8a0efb8b101665a843205eab3d67ab09cb2d9a8d ]
+
+Commit 3885c2b463f6 ("MIPS: CM: Add support for reporting CM cache
+errors") adds cm2_causes[] array with map of error type ID and
+pointers to the short description string. There is a mistake in
+the table, since according to MIPS32 manual CM2_ERROR_TYPE = {17,18}
+correspond to INTVN_WR_ERR and INTVN_RD_ERR, while the table
+claims they have {0x17,0x18} codes. This is obviously hex-dec
+copy-paste bug. Moreover codes {0x18 - 0x1a} indicate L2 ECC errors.
+
+Fixes: 3885c2b463f6 ("MIPS: CM: Add support for reporting CM cache errors")
+Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
+Cc: Alexey Malahov <Alexey.Malahov@baikalelectronics.ru>
+Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
+Cc: Paul Burton <paulburton@kernel.org>
+Cc: Ralf Baechle <ralf@linux-mips.org>
+Cc: Arnd Bergmann <arnd@arndb.de>
+Cc: Rob Herring <robh+dt@kernel.org>
+Cc: linux-pm@vger.kernel.org
+Cc: devicetree@vger.kernel.org
+Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ arch/mips/kernel/mips-cm.c | 6 +++---
+ 1 file changed, 3 insertions(+), 3 deletions(-)
+
+diff --git a/arch/mips/kernel/mips-cm.c b/arch/mips/kernel/mips-cm.c
+index 7f3f136572de..50d3d74001cb 100644
+--- a/arch/mips/kernel/mips-cm.c
++++ b/arch/mips/kernel/mips-cm.c
+@@ -123,9 +123,9 @@ static char *cm2_causes[32] = {
+ "COH_RD_ERR", "MMIO_WR_ERR", "MMIO_RD_ERR", "0x07",
+ "0x08", "0x09", "0x0a", "0x0b",
+ "0x0c", "0x0d", "0x0e", "0x0f",
+- "0x10", "0x11", "0x12", "0x13",
+- "0x14", "0x15", "0x16", "INTVN_WR_ERR",
+- "INTVN_RD_ERR", "0x19", "0x1a", "0x1b",
++ "0x10", "INTVN_WR_ERR", "INTVN_RD_ERR", "0x13",
++ "0x14", "0x15", "0x16", "0x17",
++ "0x18", "0x19", "0x1a", "0x1b",
+ "0x1c", "0x1d", "0x1e", "0x1f"
+ };
+
+--
+2.25.1
+
--- /dev/null
+From d3ef8ce0b9787082ff7548a16cca5d83b7fee72c Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 27 May 2020 14:11:30 +0800
+Subject: MIPS: Fix IRQ tracing when call handle_fpe() and handle_msa_fpe()
+
+From: YuanJunQing <yuanjunqing66@163.com>
+
+[ Upstream commit 31e1b3efa802f97a17628dde280006c4cee4ce5e ]
+
+Register "a1" is unsaved in this function,
+ when CONFIG_TRACE_IRQFLAGS is enabled,
+ the TRACE_IRQS_OFF macro will call trace_hardirqs_off(),
+ and this may change register "a1".
+ The changed register "a1" as argument will be send
+ to do_fpe() and do_msa_fpe().
+
+Signed-off-by: YuanJunQing <yuanjunqing66@163.com>
+Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ arch/mips/kernel/genex.S | 6 +++---
+ 1 file changed, 3 insertions(+), 3 deletions(-)
+
+diff --git a/arch/mips/kernel/genex.S b/arch/mips/kernel/genex.S
+index 37b9383eacd3..cf74a963839f 100644
+--- a/arch/mips/kernel/genex.S
++++ b/arch/mips/kernel/genex.S
+@@ -431,20 +431,20 @@ NESTED(nmi_handler, PT_SIZE, sp)
+ .endm
+
+ .macro __build_clear_fpe
++ CLI
++ TRACE_IRQS_OFF
+ .set push
+ /* gas fails to assemble cfc1 for some archs (octeon).*/ \
+ .set mips1
+ SET_HARDFLOAT
+ cfc1 a1, fcr31
+ .set pop
+- CLI
+- TRACE_IRQS_OFF
+ .endm
+
+ .macro __build_clear_msa_fpe
+- _cfcmsa a1, MSA_CSR
+ CLI
+ TRACE_IRQS_OFF
++ _cfcmsa a1, MSA_CSR
+ .endm
+
+ .macro __build_clear_ade
+--
+2.25.1
+
--- /dev/null
+From eb967796112d18c337e4832bb43e0a4b794ba7d2 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Sat, 16 May 2020 10:15:48 +0800
+Subject: MIPS: Loongson: Build ATI Radeon GPU driver as module
+
+From: Tiezhu Yang <yangtiezhu@loongson.cn>
+
+[ Upstream commit a44de7497f91834df0b8b6d459e259788ba66794 ]
+
+When ATI Radeon GPU driver has been compiled directly into the kernel
+instead of as a module, we should make sure the firmware for the model
+(check available ones in /lib/firmware/radeon) is built-in to the kernel
+as well, otherwise there exists the following fatal error during GPU init,
+change CONFIG_DRM_RADEON=y to CONFIG_DRM_RADEON=m to fix it.
+
+[ 1.900997] [drm] Loading RS780 Microcode
+[ 1.905077] radeon 0000:01:05.0: Direct firmware load for radeon/RS780_pfp.bin failed with error -2
+[ 1.914140] r600_cp: Failed to load firmware "radeon/RS780_pfp.bin"
+[ 1.920405] [drm:r600_init] *ERROR* Failed to load firmware!
+[ 1.926069] radeon 0000:01:05.0: Fatal error during GPU init
+[ 1.931729] [drm] radeon: finishing device.
+
+Fixes: 024e6a8b5bb1 ("MIPS: Loongson: Add a Loongson-3 default config file")
+Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
+Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ arch/mips/configs/loongson3_defconfig | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/arch/mips/configs/loongson3_defconfig b/arch/mips/configs/loongson3_defconfig
+index 324dfee23dfb..c871e40b8878 100644
+--- a/arch/mips/configs/loongson3_defconfig
++++ b/arch/mips/configs/loongson3_defconfig
+@@ -250,7 +250,7 @@ CONFIG_MEDIA_CAMERA_SUPPORT=y
+ CONFIG_MEDIA_USB_SUPPORT=y
+ CONFIG_USB_VIDEO_CLASS=m
+ CONFIG_DRM=y
+-CONFIG_DRM_RADEON=y
++CONFIG_DRM_RADEON=m
+ CONFIG_FB_RADEON=y
+ CONFIG_LCD_CLASS_DEVICE=y
+ CONFIG_LCD_PLATFORM=m
+--
+2.25.1
+
--- /dev/null
+From 188cc3334d07bf0a6b4ae0aa372d95355d347659 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 21 May 2020 03:34:37 +0300
+Subject: mips: MAAR: Use more precise address mask
+
+From: Serge Semin <Sergey.Semin@baikalelectronics.ru>
+
+[ Upstream commit bbb5946eb545fab8ad8f46bce8a803e1c0c39d47 ]
+
+Indeed according to the MIPS32 Privileged Resource Architecgture the MAAR
+pair register address field either takes [12:31] bits for non-XPA systems
+and [12:55] otherwise. In any case the current address mask is just
+wrong for 64-bit and 32-bits XPA chips. So lets extend it to 59-bits
+of physical address value. This shall cover the 64-bits architecture and
+systems with XPA enabled, and won't cause any problem for non-XPA 32-bit
+systems, since address values exceeding the architecture specific MAAR
+mask will be just truncated with setting zeros in the unsupported upper
+bits.
+
+Co-developed-by: Alexey Malahov <Alexey.Malahov@baikalelectronics.ru>
+Signed-off-by: Alexey Malahov <Alexey.Malahov@baikalelectronics.ru>
+Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
+Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
+Cc: Paul Burton <paulburton@kernel.org>
+Cc: Ralf Baechle <ralf@linux-mips.org>
+Cc: Arnd Bergmann <arnd@arndb.de>
+Cc: Rob Herring <robh+dt@kernel.org>
+Cc: devicetree@vger.kernel.org
+Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ arch/mips/include/asm/mipsregs.h | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/arch/mips/include/asm/mipsregs.h b/arch/mips/include/asm/mipsregs.h
+index a6810923b3f0..a7f9acb42034 100644
+--- a/arch/mips/include/asm/mipsregs.h
++++ b/arch/mips/include/asm/mipsregs.h
+@@ -737,7 +737,7 @@
+
+ /* MAAR bit definitions */
+ #define MIPS_MAAR_VH (_U64CAST_(1) << 63)
+-#define MIPS_MAAR_ADDR ((BIT_ULL(BITS_PER_LONG - 12) - 1) << 12)
++#define MIPS_MAAR_ADDR GENMASK_ULL(55, 12)
+ #define MIPS_MAAR_ADDR_SHIFT 12
+ #define MIPS_MAAR_S (_ULCAST_(1) << 1)
+ #define MIPS_MAAR_VL (_ULCAST_(1) << 0)
+--
+2.25.1
+
--- /dev/null
+From 541976f858b04b7245b4dd6a10650f254b7c44cd Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 21 Apr 2020 19:59:46 +0800
+Subject: MIPS: Make sparse_init() using top-down allocation
+
+From: Tiezhu Yang <yangtiezhu@loongson.cn>
+
+[ Upstream commit 269b3a9ac538c4ae87f84be640b9fa89914a2489 ]
+
+In the current code, if CONFIG_SWIOTLB is set, when failed to get IO TLB
+memory from the low pages by plat_swiotlb_setup(), it may lead to the boot
+process failed with kernel panic.
+
+(1) On the Loongson and SiByte platform
+arch/mips/loongson64/dma.c
+arch/mips/sibyte/common/dma.c
+void __init plat_swiotlb_setup(void)
+{
+ swiotlb_init(1);
+}
+
+kernel/dma/swiotlb.c
+void __init
+swiotlb_init(int verbose)
+{
+...
+ vstart = memblock_alloc_low(PAGE_ALIGN(bytes), PAGE_SIZE);
+ if (vstart && !swiotlb_init_with_tbl(vstart, io_tlb_nslabs, verbose))
+ return;
+...
+ pr_warn("Cannot allocate buffer");
+ no_iotlb_memory = true;
+}
+
+phys_addr_t swiotlb_tbl_map_single()
+{
+...
+ if (no_iotlb_memory)
+ panic("Can not allocate SWIOTLB buffer earlier ...");
+...
+}
+
+(2) On the Cavium OCTEON platform
+arch/mips/cavium-octeon/dma-octeon.c
+void __init plat_swiotlb_setup(void)
+{
+...
+ octeon_swiotlb = memblock_alloc_low(swiotlbsize, PAGE_SIZE);
+ if (!octeon_swiotlb)
+ panic("%s: Failed to allocate %zu bytes align=%lx\n",
+ __func__, swiotlbsize, PAGE_SIZE);
+...
+}
+
+Because IO_TLB_DEFAULT_SIZE is 64M, if the rest size of low memory is less
+than 64M when call plat_swiotlb_setup(), we can easily reproduce the panic
+case.
+
+In order to reduce the possibility of kernel panic when failed to get IO
+TLB memory under CONFIG_SWIOTLB, it is better to allocate low memory as
+small as possible before plat_swiotlb_setup(), so make sparse_init() using
+top-down allocation.
+
+Reported-by: Juxin Gao <gaojuxin@loongson.cn>
+Co-developed-by: Juxin Gao <gaojuxin@loongson.cn>
+Signed-off-by: Juxin Gao <gaojuxin@loongson.cn>
+Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
+Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ arch/mips/kernel/setup.c | 10 ++++++++++
+ 1 file changed, 10 insertions(+)
+
+diff --git a/arch/mips/kernel/setup.c b/arch/mips/kernel/setup.c
+index 05ed4ed411c7..abd7ee9e90ab 100644
+--- a/arch/mips/kernel/setup.c
++++ b/arch/mips/kernel/setup.c
+@@ -911,7 +911,17 @@ static void __init arch_mem_init(char **cmdline_p)
+ BOOTMEM_DEFAULT);
+ #endif
+ device_tree_init();
++
++ /*
++ * In order to reduce the possibility of kernel panic when failed to
++ * get IO TLB memory under CONFIG_SWIOTLB, it is better to allocate
++ * low memory as small as possible before plat_swiotlb_setup(), so
++ * make sparse_init() using top-down allocation.
++ */
++ memblock_set_bottom_up(false);
+ sparse_init();
++ memblock_set_bottom_up(true);
++
+ plat_swiotlb_setup();
+
+ dma_contiguous_reserve(PFN_PHYS(max_low_pfn));
+--
+2.25.1
+
--- /dev/null
+From 31ac65bc9db26655626896054298b7ccadd4dc4c Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 6 May 2020 13:52:45 +0800
+Subject: MIPS: Truncate link address into 32bit for 32bit kernel
+
+From: Jiaxun Yang <jiaxun.yang@flygoat.com>
+
+[ Upstream commit ff487d41036035376e47972c7c522490b839ab37 ]
+
+LLD failed to link vmlinux with 64bit load address for 32bit ELF
+while bfd will strip 64bit address into 32bit silently.
+To fix LLD build, we should truncate load address provided by platform
+into 32bit for 32bit kernel.
+
+Signed-off-by: Jiaxun Yang <jiaxun.yang@flygoat.com>
+Link: https://github.com/ClangBuiltLinux/linux/issues/786
+Link: https://sourceware.org/bugzilla/show_bug.cgi?id=25784
+Reviewed-by: Fangrui Song <maskray@google.com>
+Reviewed-by: Kees Cook <keescook@chromium.org>
+Tested-by: Nathan Chancellor <natechancellor@gmail.com>
+Cc: Maciej W. Rozycki <macro@linux-mips.org>
+Tested-by: Nick Desaulniers <ndesaulniers@google.com>
+Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ arch/mips/Makefile | 13 ++++++++++++-
+ arch/mips/boot/compressed/Makefile | 2 +-
+ arch/mips/kernel/vmlinux.lds.S | 2 +-
+ 3 files changed, 14 insertions(+), 3 deletions(-)
+
+diff --git a/arch/mips/Makefile b/arch/mips/Makefile
+index 5977884b008e..a4a06d173858 100644
+--- a/arch/mips/Makefile
++++ b/arch/mips/Makefile
+@@ -279,12 +279,23 @@ ifdef CONFIG_64BIT
+ endif
+ endif
+
++# When linking a 32-bit executable the LLVM linker cannot cope with a
++# 32-bit load address that has been sign-extended to 64 bits. Simply
++# remove the upper 32 bits then, as it is safe to do so with other
++# linkers.
++ifdef CONFIG_64BIT
++ load-ld = $(load-y)
++else
++ load-ld = $(subst 0xffffffff,0x,$(load-y))
++endif
++
+ KBUILD_AFLAGS += $(cflags-y)
+ KBUILD_CFLAGS += $(cflags-y)
+-KBUILD_CPPFLAGS += -DVMLINUX_LOAD_ADDRESS=$(load-y)
++KBUILD_CPPFLAGS += -DVMLINUX_LOAD_ADDRESS=$(load-y) -DLINKER_LOAD_ADDRESS=$(load-ld)
+ KBUILD_CPPFLAGS += -DDATAOFFSET=$(if $(dataoffset-y),$(dataoffset-y),0)
+
+ bootvars-y = VMLINUX_LOAD_ADDRESS=$(load-y) \
++ LINKER_LOAD_ADDRESS=$(load-ld) \
+ VMLINUX_ENTRY_ADDRESS=$(entry-y) \
+ PLATFORM="$(platform-y)" \
+ ITS_INPUTS="$(its-y)"
+diff --git a/arch/mips/boot/compressed/Makefile b/arch/mips/boot/compressed/Makefile
+index baa34e4deb78..516e593a8ee9 100644
+--- a/arch/mips/boot/compressed/Makefile
++++ b/arch/mips/boot/compressed/Makefile
+@@ -87,7 +87,7 @@ ifneq ($(zload-y),)
+ VMLINUZ_LOAD_ADDRESS := $(zload-y)
+ else
+ VMLINUZ_LOAD_ADDRESS = $(shell $(obj)/calc_vmlinuz_load_addr \
+- $(obj)/vmlinux.bin $(VMLINUX_LOAD_ADDRESS))
++ $(obj)/vmlinux.bin $(LINKER_LOAD_ADDRESS))
+ endif
+ UIMAGE_LOADADDR = $(VMLINUZ_LOAD_ADDRESS)
+
+diff --git a/arch/mips/kernel/vmlinux.lds.S b/arch/mips/kernel/vmlinux.lds.S
+index 36f2e860ba3e..be63fff95b2a 100644
+--- a/arch/mips/kernel/vmlinux.lds.S
++++ b/arch/mips/kernel/vmlinux.lds.S
+@@ -50,7 +50,7 @@ SECTIONS
+ /* . = 0xa800000000300000; */
+ . = 0xffffffff80300000;
+ #endif
+- . = VMLINUX_LOAD_ADDRESS;
++ . = LINKER_LOAD_ADDRESS;
+ /* read-only */
+ _text = .; /* Text and read-only data */
+ .text : {
+--
+2.25.1
+
--- /dev/null
+From 1bbcec14ce8c24371d2987096de589f95e25a746 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 26 May 2020 18:22:01 +0800
+Subject: mmc: sdhci-esdhc-imx: fix the mask for tuning start point
+
+From: Haibo Chen <haibo.chen@nxp.com>
+
+[ Upstream commit 1194be8c949b8190b2882ad8335a5d98aa50c735 ]
+
+According the RM, the bit[6~0] of register ESDHC_TUNING_CTRL is
+TUNING_START_TAP, bit[7] of this register is to disable the command
+CRC check for standard tuning. So fix it here.
+
+Fixes: d87fc9663688 ("mmc: sdhci-esdhc-imx: support setting tuning start point")
+Signed-off-by: Haibo Chen <haibo.chen@nxp.com>
+Link: https://lore.kernel.org/r/1590488522-9292-1-git-send-email-haibo.chen@nxp.com
+Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/mmc/host/sdhci-esdhc-imx.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/drivers/mmc/host/sdhci-esdhc-imx.c b/drivers/mmc/host/sdhci-esdhc-imx.c
+index 8c0b80a54e4d..6d1ac9443eb2 100644
+--- a/drivers/mmc/host/sdhci-esdhc-imx.c
++++ b/drivers/mmc/host/sdhci-esdhc-imx.c
+@@ -79,7 +79,7 @@
+ #define ESDHC_STD_TUNING_EN (1 << 24)
+ /* NOTE: the minimum valid tuning start tap for mx6sl is 1 */
+ #define ESDHC_TUNING_START_TAP_DEFAULT 0x1
+-#define ESDHC_TUNING_START_TAP_MASK 0xff
++#define ESDHC_TUNING_START_TAP_MASK 0x7f
+ #define ESDHC_TUNING_STEP_MASK 0x00070000
+ #define ESDHC_TUNING_STEP_SHIFT 16
+
+--
+2.25.1
+
--- /dev/null
+From d2bf437cda54110749fd32e9ffaa49872a0efe19 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Mon, 20 Apr 2020 11:50:24 +0530
+Subject: mmc: sdhci-msm: Set SDHCI_QUIRK_MULTIBLOCK_READ_ACMD12 quirk
+
+From: Veerabhadrarao Badiganti <vbadigan@codeaurora.org>
+
+[ Upstream commit d863cb03fb2aac07f017b2a1d923cdbc35021280 ]
+
+sdhci-msm can support auto cmd12.
+So enable SDHCI_QUIRK_MULTIBLOCK_READ_ACMD12 quirk.
+
+Signed-off-by: Veerabhadrarao Badiganti <vbadigan@codeaurora.org>
+Acked-by: Adrian Hunter <adrian.hunter@intel.com>
+Link: https://lore.kernel.org/r/1587363626-20413-3-git-send-email-vbadigan@codeaurora.org
+Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/mmc/host/sdhci-msm.c | 4 +++-
+ 1 file changed, 3 insertions(+), 1 deletion(-)
+
+diff --git a/drivers/mmc/host/sdhci-msm.c b/drivers/mmc/host/sdhci-msm.c
+index b035eec302da..75cf66ffc705 100644
+--- a/drivers/mmc/host/sdhci-msm.c
++++ b/drivers/mmc/host/sdhci-msm.c
+@@ -1168,7 +1168,9 @@ static const struct sdhci_pltfm_data sdhci_msm_pdata = {
+ .quirks = SDHCI_QUIRK_BROKEN_CARD_DETECTION |
+ SDHCI_QUIRK_NO_CARD_NO_RESET |
+ SDHCI_QUIRK_SINGLE_POWER_WRITE |
+- SDHCI_QUIRK_CAP_CLOCK_BASE_BROKEN,
++ SDHCI_QUIRK_CAP_CLOCK_BASE_BROKEN |
++ SDHCI_QUIRK_MULTIBLOCK_READ_ACMD12,
++
+ .quirks2 = SDHCI_QUIRK2_PRESET_VALUE_BROKEN,
+ .ops = &sdhci_msm_ops,
+ };
+--
+2.25.1
+
--- /dev/null
+From 91cdf044b0187f042d045bc639b8e4d59372f253 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 14 Apr 2020 18:14:10 +0200
+Subject: mmc: via-sdmmc: Respect the cmd->busy_timeout from the mmc core
+
+From: Ulf Hansson <ulf.hansson@linaro.org>
+
+[ Upstream commit 966244ccd2919e28f25555a77f204cd1c109cad8 ]
+
+Using a fixed 1s timeout for all commands (and data transfers) is a bit
+problematic.
+
+For some commands it means waiting longer than needed for the timer to
+expire, which may not a big issue, but still. For other commands, like for
+an erase (CMD38) that uses a R1B response, may require longer timeouts than
+1s. In these cases, we may end up treating the command as it failed, while
+it just needed some more time to complete successfully.
+
+Fix the problem by respecting the cmd->busy_timeout, which is provided by
+the mmc core.
+
+Cc: Bruce Chang <brucechang@via.com.tw>
+Cc: Harald Welte <HaraldWelte@viatech.com>
+Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
+Link: https://lore.kernel.org/r/20200414161413.3036-17-ulf.hansson@linaro.org
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/mmc/host/via-sdmmc.c | 7 ++++++-
+ 1 file changed, 6 insertions(+), 1 deletion(-)
+
+diff --git a/drivers/mmc/host/via-sdmmc.c b/drivers/mmc/host/via-sdmmc.c
+index a838bf5480d8..a863a345fc59 100644
+--- a/drivers/mmc/host/via-sdmmc.c
++++ b/drivers/mmc/host/via-sdmmc.c
+@@ -323,6 +323,8 @@ struct via_crdr_mmc_host {
+ /* some devices need a very long delay for power to stabilize */
+ #define VIA_CRDR_QUIRK_300MS_PWRDELAY 0x0001
+
++#define VIA_CMD_TIMEOUT_MS 1000
++
+ static const struct pci_device_id via_ids[] = {
+ {PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_9530,
+ PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0,},
+@@ -555,14 +557,17 @@ static void via_sdc_send_command(struct via_crdr_mmc_host *host,
+ {
+ void __iomem *addrbase;
+ struct mmc_data *data;
++ unsigned int timeout_ms;
+ u32 cmdctrl = 0;
+
+ WARN_ON(host->cmd);
+
+ data = cmd->data;
+- mod_timer(&host->timer, jiffies + HZ);
+ host->cmd = cmd;
+
++ timeout_ms = cmd->busy_timeout ? cmd->busy_timeout : VIA_CMD_TIMEOUT_MS;
++ mod_timer(&host->timer, jiffies + msecs_to_jiffies(timeout_ms));
++
+ /*Command index*/
+ cmdctrl = cmd->opcode << 8;
+
+--
+2.25.1
+
--- /dev/null
+From 1d23121327bf95855f67ed4f36e7c6d19677f780 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 15 May 2020 09:59:24 +0200
+Subject: mwifiex: Fix memory corruption in dump_station
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Pali Rohár <pali@kernel.org>
+
+[ Upstream commit 3aa42bae9c4d1641aeb36f1a8585cd1d506cf471 ]
+
+The mwifiex_cfg80211_dump_station() uses static variable for iterating
+over a linked list of all associated stations (when the driver is in UAP
+role). This has a race condition if .dump_station is called in parallel
+for multiple interfaces. This corruption can be triggered by registering
+multiple SSIDs and calling, in parallel for multiple interfaces
+ iw dev <iface> station dump
+
+[16750.719775] Unable to handle kernel paging request at virtual address dead000000000110
+...
+[16750.899173] Call trace:
+[16750.901696] mwifiex_cfg80211_dump_station+0x94/0x100 [mwifiex]
+[16750.907824] nl80211_dump_station+0xbc/0x278 [cfg80211]
+[16750.913160] netlink_dump+0xe8/0x320
+[16750.916827] netlink_recvmsg+0x1b4/0x338
+[16750.920861] ____sys_recvmsg+0x7c/0x2b0
+[16750.924801] ___sys_recvmsg+0x70/0x98
+[16750.928564] __sys_recvmsg+0x58/0xa0
+[16750.932238] __arm64_sys_recvmsg+0x28/0x30
+[16750.936453] el0_svc_common.constprop.3+0x90/0x158
+[16750.941378] do_el0_svc+0x74/0x90
+[16750.944784] el0_sync_handler+0x12c/0x1a8
+[16750.948903] el0_sync+0x114/0x140
+[16750.952312] Code: f9400003 f907f423 eb02007f 54fffd60 (b9401060)
+[16750.958583] ---[ end trace c8ad181c2f4b8576 ]---
+
+This patch drops the use of the static iterator, and instead every time
+the function is called iterates to the idx-th position of the
+linked-list.
+
+It would be better to convert the code not to use linked list for
+associated stations storage (since the chip has a limited number of
+associated stations anyway - it could just be an array). Such a change
+may be proposed in the future. In the meantime this patch can backported
+into stable kernels in this simple form.
+
+Fixes: 8baca1a34d4c ("mwifiex: dump station support in uap mode")
+Signed-off-by: Pali Rohár <pali@kernel.org>
+Acked-by: Ganapathi Bhat <ganapathi.bhat@nxp.com>
+Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
+Link: https://lore.kernel.org/r/20200515075924.13841-1-pali@kernel.org
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/wireless/marvell/mwifiex/cfg80211.c | 14 ++++++--------
+ 1 file changed, 6 insertions(+), 8 deletions(-)
+
+diff --git a/drivers/net/wireless/marvell/mwifiex/cfg80211.c b/drivers/net/wireless/marvell/mwifiex/cfg80211.c
+index 5e8e34a08b2d..79c50aebffc4 100644
+--- a/drivers/net/wireless/marvell/mwifiex/cfg80211.c
++++ b/drivers/net/wireless/marvell/mwifiex/cfg80211.c
+@@ -1451,7 +1451,8 @@ mwifiex_cfg80211_dump_station(struct wiphy *wiphy, struct net_device *dev,
+ int idx, u8 *mac, struct station_info *sinfo)
+ {
+ struct mwifiex_private *priv = mwifiex_netdev_get_priv(dev);
+- static struct mwifiex_sta_node *node;
++ struct mwifiex_sta_node *node;
++ int i;
+
+ if ((GET_BSS_ROLE(priv) == MWIFIEX_BSS_ROLE_STA) &&
+ priv->media_connected && idx == 0) {
+@@ -1461,13 +1462,10 @@ mwifiex_cfg80211_dump_station(struct wiphy *wiphy, struct net_device *dev,
+ mwifiex_send_cmd(priv, HOST_CMD_APCMD_STA_LIST,
+ HostCmd_ACT_GEN_GET, 0, NULL, true);
+
+- if (node && (&node->list == &priv->sta_list)) {
+- node = NULL;
+- return -ENOENT;
+- }
+-
+- node = list_prepare_entry(node, &priv->sta_list, list);
+- list_for_each_entry_continue(node, &priv->sta_list, list) {
++ i = 0;
++ list_for_each_entry(node, &priv->sta_list, list) {
++ if (i++ != idx)
++ continue;
+ ether_addr_copy(mac, node->mac_addr);
+ return mwifiex_dump_station_info(priv, node, sinfo);
+ }
+--
+2.25.1
+
--- /dev/null
+From 6152386a58eab013e2c816871b426223227ecb56 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 5 May 2020 10:49:20 +0800
+Subject: net: allwinner: Fix use correct return type for ndo_start_xmit()
+
+From: Yunjian Wang <wangyunjian@huawei.com>
+
+[ Upstream commit 09f6c44aaae0f1bdb8b983d7762676d5018c53bc ]
+
+The method ndo_start_xmit() returns a value of type netdev_tx_t. Fix
+the ndo function to use the correct type. And emac_start_xmit() can
+leak one skb if 'channel' == 3.
+
+Signed-off-by: Yunjian Wang <wangyunjian@huawei.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/ethernet/allwinner/sun4i-emac.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/drivers/net/ethernet/allwinner/sun4i-emac.c b/drivers/net/ethernet/allwinner/sun4i-emac.c
+index 3143de45baaa..c458b81ba63a 100644
+--- a/drivers/net/ethernet/allwinner/sun4i-emac.c
++++ b/drivers/net/ethernet/allwinner/sun4i-emac.c
+@@ -433,7 +433,7 @@ static void emac_timeout(struct net_device *dev)
+ /* Hardware start transmission.
+ * Send a packet to media from the upper layer.
+ */
+-static int emac_start_xmit(struct sk_buff *skb, struct net_device *dev)
++static netdev_tx_t emac_start_xmit(struct sk_buff *skb, struct net_device *dev)
+ {
+ struct emac_board_info *db = netdev_priv(dev);
+ unsigned long channel;
+@@ -441,7 +441,7 @@ static int emac_start_xmit(struct sk_buff *skb, struct net_device *dev)
+
+ channel = db->tx_fifo_stat & 3;
+ if (channel == 3)
+- return 1;
++ return NETDEV_TX_BUSY;
+
+ channel = (channel == 1 ? 1 : 0);
+
+--
+2.25.1
+
--- /dev/null
+From 52f09107d2dbf759c9b7ba4006cc7297cfc4861f Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 29 Apr 2020 13:02:00 -0700
+Subject: net: bcmgenet: set Rx mode before starting netif
+
+From: Doug Berger <opendmb@gmail.com>
+
+[ Upstream commit 72f96347628e73dbb61b307f18dd19293cc6792a ]
+
+This commit explicitly calls the bcmgenet_set_rx_mode() function when
+the network interface is started. This function is normally called by
+ndo_set_rx_mode when the flags are changed, but apparently not when
+the driver is suspended and resumed.
+
+This change ensures that address filtering or promiscuous mode are
+properly restored by the driver after the MAC may have been reset.
+
+Fixes: b6e978e50444 ("net: bcmgenet: add suspend/resume callbacks")
+Signed-off-by: Doug Berger <opendmb@gmail.com>
+Acked-by: Florian Fainelli <f.fainelli@gmail.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/ethernet/broadcom/genet/bcmgenet.c | 4 ++++
+ 1 file changed, 4 insertions(+)
+
+diff --git a/drivers/net/ethernet/broadcom/genet/bcmgenet.c b/drivers/net/ethernet/broadcom/genet/bcmgenet.c
+index 38391230ca86..7d3cbbd88a00 100644
+--- a/drivers/net/ethernet/broadcom/genet/bcmgenet.c
++++ b/drivers/net/ethernet/broadcom/genet/bcmgenet.c
+@@ -72,6 +72,9 @@
+ #define GENET_RDMA_REG_OFF (priv->hw_params->rdma_offset + \
+ TOTAL_DESC * DMA_DESC_SIZE)
+
++/* Forward declarations */
++static void bcmgenet_set_rx_mode(struct net_device *dev);
++
+ static inline void bcmgenet_writel(u32 value, void __iomem *offset)
+ {
+ /* MIPS chips strapped for BE will automagically configure the
+@@ -2858,6 +2861,7 @@ static void bcmgenet_netif_start(struct net_device *dev)
+ struct bcmgenet_priv *priv = netdev_priv(dev);
+
+ /* Start the network engine */
++ bcmgenet_set_rx_mode(dev);
+ bcmgenet_enable_rx_napi(priv);
+ bcmgenet_enable_tx_napi(priv);
+
+--
+2.25.1
+
--- /dev/null
+From e2d6b51e3151e5e515e200e0ca0714b3fe163d96 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Sun, 3 May 2020 09:52:11 +0000
+Subject: net: ena: fix error returning in ena_com_get_hash_function()
+
+From: Arthur Kiyanovski <akiyano@amazon.com>
+
+[ Upstream commit e9a1de378dd46375f9abfd8de1e6f59ee114a793 ]
+
+In case the "func" parameter is NULL we now return "-EINVAL".
+This shouldn't happen in general, but when it does happen, this is the
+proper way to handle it.
+
+We also check func for NULL in the beginning of the function, as there
+is no reason to do all the work and realize in the end of the function
+it was useless.
+
+Signed-off-by: Sameeh Jubran <sameehj@amazon.com>
+Signed-off-by: Arthur Kiyanovski <akiyano@amazon.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/ethernet/amazon/ena/ena_com.c | 6 ++++--
+ 1 file changed, 4 insertions(+), 2 deletions(-)
+
+diff --git a/drivers/net/ethernet/amazon/ena/ena_com.c b/drivers/net/ethernet/amazon/ena/ena_com.c
+index dc9149a32f41..bb1710ff910a 100644
+--- a/drivers/net/ethernet/amazon/ena/ena_com.c
++++ b/drivers/net/ethernet/amazon/ena/ena_com.c
+@@ -2131,6 +2131,9 @@ int ena_com_get_hash_function(struct ena_com_dev *ena_dev,
+ rss->hash_key;
+ int rc;
+
++ if (unlikely(!func))
++ return -EINVAL;
++
+ rc = ena_com_get_feature_ex(ena_dev, &get_resp,
+ ENA_ADMIN_RSS_HASH_FUNCTION,
+ rss->hash_key_dma_addr,
+@@ -2143,8 +2146,7 @@ int ena_com_get_hash_function(struct ena_com_dev *ena_dev,
+ if (rss->hash_func)
+ rss->hash_func--;
+
+- if (func)
+- *func = rss->hash_func;
++ *func = rss->hash_func;
+
+ if (key)
+ memcpy(key, hash_key->key, (size_t)(hash_key->keys_num) << 2);
+--
+2.25.1
+
--- /dev/null
+From 8ceda920e71d125affcb11d36bf6fff316f3b9e9 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Mon, 27 Apr 2020 12:15:07 +0000
+Subject: net: lpc-enet: fix error return code in lpc_mii_init()
+
+From: Wei Yongjun <weiyongjun1@huawei.com>
+
+[ Upstream commit 88ec7cb22ddde725ed4ce15991f0bd9dd817fd85 ]
+
+Fix to return a negative error code from the error handling
+case instead of 0, as done elsewhere in this function.
+
+Fixes: b7370112f519 ("lpc32xx: Added ethernet driver")
+Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
+Acked-by: Vladimir Zapolskiy <vz@mleia.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/ethernet/nxp/lpc_eth.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+diff --git a/drivers/net/ethernet/nxp/lpc_eth.c b/drivers/net/ethernet/nxp/lpc_eth.c
+index 41d30f55c946..6bd6c261f2ba 100644
+--- a/drivers/net/ethernet/nxp/lpc_eth.c
++++ b/drivers/net/ethernet/nxp/lpc_eth.c
+@@ -845,7 +845,8 @@ static int lpc_mii_init(struct netdata_local *pldat)
+ if (mdiobus_register(pldat->mii_bus))
+ goto err_out_unregister_bus;
+
+- if (lpc_mii_probe(pldat->ndev) != 0)
++ err = lpc_mii_probe(pldat->ndev);
++ if (err)
+ goto err_out_unregister_bus;
+
+ return 0;
+--
+2.25.1
+
--- /dev/null
+From f81a6e1475e45e4a8a6106e5928e34bf043d1940 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Mon, 11 May 2020 15:41:41 +0530
+Subject: net: qed*: Reduce RX and TX default ring count when running inside
+ kdump kernel
+
+From: Bhupesh Sharma <bhsharma@redhat.com>
+
+[ Upstream commit 73e030977f7884dbe1be0018bab517e8d02760f8 ]
+
+Normally kdump kernel(s) run under severe memory constraint with the
+basic idea being to save the crashdump vmcore reliably when the primary
+kernel panics/hangs.
+
+Currently the qed* ethernet driver ends up consuming a lot of memory in
+the kdump kernel, leading to kdump kernel panic when one tries to save
+the vmcore via ssh/nfs (thus utilizing the services of the underlying
+qed* network interfaces).
+
+An example OOM message log seen in the kdump kernel can be seen here
+[1], with crashkernel size reservation of 512M.
+
+Using tools like memstrack (see [2]), we can track the modules taking up
+the bulk of memory in the kdump kernel and organize the memory usage
+output as per 'highest allocator first'. An example log for the OOM case
+indicates that the qed* modules end up allocating approximately 216M
+memory, which is a large part of the total crashkernel size:
+
+ dracut-pre-pivot[676]: ======== Report format module_summary: ========
+ dracut-pre-pivot[676]: Module qed using 149.6MB (2394 pages), peak allocation 149.6MB (2394 pages)
+ dracut-pre-pivot[676]: Module qede using 65.3MB (1045 pages), peak allocation 65.3MB (1045 pages)
+
+This patch reduces the default RX and TX ring count from 1024 to 64
+when running inside kdump kernel, which leads to a significant memory
+saving.
+
+An example log with the patch applied shows the reduced memory
+allocation in the kdump kernel:
+ dracut-pre-pivot[674]: ======== Report format module_summary: ========
+ dracut-pre-pivot[674]: Module qed using 141.8MB (2268 pages), peak allocation 141.8MB (2268 pages)
+ <..snip..>
+[dracut-pre-pivot[674]: Module qede using 4.8MB (76 pages), peak allocation 4.9MB (78 pages)
+
+Tested crashdump vmcore save via ssh/nfs protocol using underlying qed*
+network interface after applying this patch.
+
+[1] OOM log:
+------------
+
+ kworker/0:6: page allocation failure: order:6,
+ mode:0x60c0c0(GFP_KERNEL|__GFP_COMP|__GFP_ZERO), nodemask=(null)
+ kworker/0:6 cpuset=/ mems_allowed=0
+ CPU: 0 PID: 145 Comm: kworker/0:6 Not tainted 4.18.0-109.el8.aarch64 #1
+ Hardware name: To be filled by O.E.M. Saber/Saber, BIOS 0ACKL025
+ 01/18/2019
+ Workqueue: events work_for_cpu_fn
+ Call trace:
+ dump_backtrace+0x0/0x188
+ show_stack+0x24/0x30
+ dump_stack+0x90/0xb4
+ warn_alloc+0xf4/0x178
+ __alloc_pages_nodemask+0xcac/0xd58
+ alloc_pages_current+0x8c/0xf8
+ kmalloc_order_trace+0x38/0x108
+ qed_iov_alloc+0x40/0x248 [qed]
+ qed_resc_alloc+0x224/0x518 [qed]
+ qed_slowpath_start+0x254/0x928 [qed]
+ __qede_probe+0xf8/0x5e0 [qede]
+ qede_probe+0x68/0xd8 [qede]
+ local_pci_probe+0x44/0xa8
+ work_for_cpu_fn+0x20/0x30
+ process_one_work+0x1ac/0x3e8
+ worker_thread+0x44/0x448
+ kthread+0x130/0x138
+ ret_from_fork+0x10/0x18
+ Cannot start slowpath
+ qede: probe of 0000:05:00.1 failed with error -12
+
+[2]. Memstrack tool: https://github.com/ryncsn/memstrack
+
+Cc: kexec@lists.infradead.org
+Cc: linux-kernel@vger.kernel.org
+Cc: Ariel Elior <aelior@marvell.com>
+Cc: GR-everest-linux-l2@marvell.com
+Cc: Manish Chopra <manishc@marvell.com>
+Cc: David S. Miller <davem@davemloft.net>
+Signed-off-by: Bhupesh Sharma <bhsharma@redhat.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/ethernet/qlogic/qede/qede.h | 2 ++
+ drivers/net/ethernet/qlogic/qede/qede_main.c | 11 +++++++++--
+ 2 files changed, 11 insertions(+), 2 deletions(-)
+
+diff --git a/drivers/net/ethernet/qlogic/qede/qede.h b/drivers/net/ethernet/qlogic/qede/qede.h
+index a80531b5aecc..c132b08cefde 100644
+--- a/drivers/net/ethernet/qlogic/qede/qede.h
++++ b/drivers/net/ethernet/qlogic/qede/qede.h
+@@ -528,12 +528,14 @@ void qede_update_rx_prod(struct qede_dev *edev, struct qede_rx_queue *rxq);
+ #define RX_RING_SIZE ((u16)BIT(RX_RING_SIZE_POW))
+ #define NUM_RX_BDS_MAX (RX_RING_SIZE - 1)
+ #define NUM_RX_BDS_MIN 128
++#define NUM_RX_BDS_KDUMP_MIN 63
+ #define NUM_RX_BDS_DEF ((u16)BIT(10) - 1)
+
+ #define TX_RING_SIZE_POW 13
+ #define TX_RING_SIZE ((u16)BIT(TX_RING_SIZE_POW))
+ #define NUM_TX_BDS_MAX (TX_RING_SIZE - 1)
+ #define NUM_TX_BDS_MIN 128
++#define NUM_TX_BDS_KDUMP_MIN 63
+ #define NUM_TX_BDS_DEF NUM_TX_BDS_MAX
+
+ #define QEDE_MIN_PKT_LEN 64
+diff --git a/drivers/net/ethernet/qlogic/qede/qede_main.c b/drivers/net/ethernet/qlogic/qede/qede_main.c
+index dab202f343c6..8bb734486bf3 100644
+--- a/drivers/net/ethernet/qlogic/qede/qede_main.c
++++ b/drivers/net/ethernet/qlogic/qede/qede_main.c
+@@ -29,6 +29,7 @@
+ * CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+ * SOFTWARE.
+ */
++#include <linux/crash_dump.h>
+ #include <linux/module.h>
+ #include <linux/pci.h>
+ #include <linux/version.h>
+@@ -624,8 +625,14 @@ static struct qede_dev *qede_alloc_etherdev(struct qed_dev *cdev,
+ edev->dp_module = dp_module;
+ edev->dp_level = dp_level;
+ edev->ops = qed_ops;
+- edev->q_num_rx_buffers = NUM_RX_BDS_DEF;
+- edev->q_num_tx_buffers = NUM_TX_BDS_DEF;
++
++ if (is_kdump_kernel()) {
++ edev->q_num_rx_buffers = NUM_RX_BDS_KDUMP_MIN;
++ edev->q_num_tx_buffers = NUM_TX_BDS_KDUMP_MIN;
++ } else {
++ edev->q_num_rx_buffers = NUM_RX_BDS_DEF;
++ edev->q_num_tx_buffers = NUM_TX_BDS_DEF;
++ }
+
+ DP_INFO(edev, "Allocated netdev with %d tx queues and %d rx queues\n",
+ info->num_queues, info->num_queues);
+--
+2.25.1
+
--- /dev/null
+From 9c11e8f633d8e7dce4da211db253be1dc920c653 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Sat, 30 May 2020 10:41:50 +0800
+Subject: net: vmxnet3: fix possible buffer overflow caused by bad DMA value in
+ vmxnet3_get_rss()
+
+From: Jia-Ju Bai <baijiaju1990@gmail.com>
+
+[ Upstream commit 3e1c6846b9e108740ef8a37be80314053f5dd52a ]
+
+The value adapter->rss_conf is stored in DMA memory, and it is assigned
+to rssConf, so rssConf->indTableSize can be modified at anytime by
+malicious hardware. Because rssConf->indTableSize is assigned to n,
+buffer overflow may occur when the code "rssConf->indTable[n]" is
+executed.
+
+To fix this possible bug, n is checked after being used.
+
+Signed-off-by: Jia-Ju Bai <baijiaju1990@gmail.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/vmxnet3/vmxnet3_ethtool.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+diff --git a/drivers/net/vmxnet3/vmxnet3_ethtool.c b/drivers/net/vmxnet3/vmxnet3_ethtool.c
+index 2ff27314e047..66c6c07c7a16 100644
+--- a/drivers/net/vmxnet3/vmxnet3_ethtool.c
++++ b/drivers/net/vmxnet3/vmxnet3_ethtool.c
+@@ -692,6 +692,8 @@ vmxnet3_get_rss(struct net_device *netdev, u32 *p, u8 *key, u8 *hfunc)
+ *hfunc = ETH_RSS_HASH_TOP;
+ if (!p)
+ return 0;
++ if (n > UPT1_RSS_MAX_IND_TABLE_SIZE)
++ return 0;
+ while (n--)
+ p[n] = rssConf->indTable[n];
+ return 0;
+--
+2.25.1
+
--- /dev/null
+From cc376f02961dcc14233b8f8d9b302927ce3a7696 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 24 Apr 2020 21:55:34 +0200
+Subject: netfilter: nft_nat: return EOPNOTSUPP if type or flags are not
+ supported
+
+From: Pablo Neira Ayuso <pablo@netfilter.org>
+
+[ Upstream commit 0d7c83463fdf7841350f37960a7abadd3e650b41 ]
+
+Instead of EINVAL which should be used for malformed netlink messages.
+
+Fixes: eb31628e37a0 ("netfilter: nf_tables: Add support for IPv6 NAT")
+Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ net/netfilter/nft_nat.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/net/netfilter/nft_nat.c b/net/netfilter/nft_nat.c
+index ed548d06b6dd..a18cceecef88 100644
+--- a/net/netfilter/nft_nat.c
++++ b/net/netfilter/nft_nat.c
+@@ -135,7 +135,7 @@ static int nft_nat_init(const struct nft_ctx *ctx, const struct nft_expr *expr,
+ priv->type = NF_NAT_MANIP_DST;
+ break;
+ default:
+- return -EINVAL;
++ return -EOPNOTSUPP;
+ }
+
+ if (tb[NFTA_NAT_FAMILY] == NULL)
+@@ -202,7 +202,7 @@ static int nft_nat_init(const struct nft_ctx *ctx, const struct nft_expr *expr,
+ if (tb[NFTA_NAT_FLAGS]) {
+ priv->flags = ntohl(nla_get_be32(tb[NFTA_NAT_FLAGS]));
+ if (priv->flags & ~NF_NAT_RANGE_MASK)
+- return -EINVAL;
++ return -EOPNOTSUPP;
+ }
+
+ return nf_ct_netns_get(ctx->net, family);
+--
+2.25.1
+
--- /dev/null
+From e7bd8510e973170ba126f82da8d9cb37903ffe16 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Sat, 4 Apr 2020 10:11:28 +0200
+Subject: nvme: refine the Qemu Identify CNS quirk
+
+From: Christoph Hellwig <hch@lst.de>
+
+[ Upstream commit b9a5c3d4c34d8bd9fd75f7f28d18a57cb68da237 ]
+
+Add a helper to check if we can use Identify CNS values > 1, and refine
+the Qemu quirk to not apply to reported versions larger than 1.1, as the
+Qemu implementation had been fixed by then.
+
+Signed-off-by: Christoph Hellwig <hch@lst.de>
+Reviewed-by: Keith Busch <kbusch@kernel.org>
+Reviewed-by: Sagi Grimberg <sagi@grimberg.me>
+Signed-off-by: Jens Axboe <axboe@kernel.dk>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/nvme/host/core.c | 16 ++++++++++++++--
+ 1 file changed, 14 insertions(+), 2 deletions(-)
+
+diff --git a/drivers/nvme/host/core.c b/drivers/nvme/host/core.c
+index a760c449f4a9..2d95755092e3 100644
+--- a/drivers/nvme/host/core.c
++++ b/drivers/nvme/host/core.c
+@@ -758,6 +758,19 @@ void nvme_stop_keep_alive(struct nvme_ctrl *ctrl)
+ }
+ EXPORT_SYMBOL_GPL(nvme_stop_keep_alive);
+
++/*
++ * In NVMe 1.0 the CNS field was just a binary controller or namespace
++ * flag, thus sending any new CNS opcodes has a big chance of not working.
++ * Qemu unfortunately had that bug after reporting a 1.1 version compliance
++ * (but not for any later version).
++ */
++static bool nvme_ctrl_limited_cns(struct nvme_ctrl *ctrl)
++{
++ if (ctrl->quirks & NVME_QUIRK_IDENTIFY_CNS)
++ return ctrl->vs < NVME_VS(1, 2, 0);
++ return ctrl->vs < NVME_VS(1, 1, 0);
++}
++
+ static int nvme_identify_ctrl(struct nvme_ctrl *dev, struct nvme_id_ctrl **id)
+ {
+ struct nvme_command c = { };
+@@ -2538,8 +2551,7 @@ static void nvme_scan_work(struct work_struct *work)
+ return;
+
+ nn = le32_to_cpu(id->nn);
+- if (ctrl->vs >= NVME_VS(1, 1, 0) &&
+- !(ctrl->quirks & NVME_QUIRK_IDENTIFY_CNS)) {
++ if (!nvme_ctrl_limited_cns(ctrl)) {
+ if (!nvme_scan_ns_list(ctrl, nn))
+ goto done;
+ }
+--
+2.25.1
+
--- /dev/null
+From 6b13c4a99878e5bd63bc99841b739a62c6cc8f3a Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 27 Mar 2020 15:28:41 +0000
+Subject: objtool: Ignore empty alternatives
+
+From: Julien Thierry <jthierry@redhat.com>
+
+[ Upstream commit 7170cf47d16f1ba29eca07fd818870b7af0a93a5 ]
+
+The .alternatives section can contain entries with no original
+instructions. Objtool will currently crash when handling such an entry.
+
+Just skip that entry, but still give a warning to discourage useless
+entries.
+
+Signed-off-by: Julien Thierry <jthierry@redhat.com>
+Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
+Reviewed-by: Miroslav Benes <mbenes@suse.cz>
+Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
+Signed-off-by: Ingo Molnar <mingo@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ tools/objtool/check.c | 6 ++++++
+ 1 file changed, 6 insertions(+)
+
+diff --git a/tools/objtool/check.c b/tools/objtool/check.c
+index 5685fe2c7a7d..247fbb5f6a38 100644
+--- a/tools/objtool/check.c
++++ b/tools/objtool/check.c
+@@ -778,6 +778,12 @@ static int add_special_section_alts(struct objtool_file *file)
+ }
+
+ if (special_alt->group) {
++ if (!special_alt->orig_len) {
++ WARN_FUNC("empty alternative entry",
++ orig_insn->sec, orig_insn->offset);
++ continue;
++ }
++
+ ret = handle_group_alt(file, special_alt, orig_insn,
+ &new_insn);
+ if (ret)
+--
+2.25.1
+
--- /dev/null
+From e9c5a2d20843ad7f99155ff4b6e58061dd503514 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 26 May 2020 17:21:12 +0800
+Subject: PCI: Don't disable decoding when mmio_always_on is set
+
+From: Jiaxun Yang <jiaxun.yang@flygoat.com>
+
+[ Upstream commit b6caa1d8c80cb71b6162cb1f1ec13aa655026c9f ]
+
+Don't disable MEM/IO decoding when a device have both non_compliant_bars
+and mmio_always_on.
+
+That would allow us quirk devices with junk in BARs but can't disable
+their decoding.
+
+Signed-off-by: Jiaxun Yang <jiaxun.yang@flygoat.com>
+Acked-by: Bjorn Helgaas <helgaas@kernel.org>
+Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/pci/probe.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
+index e23bfd9845b1..92c3abe0b2b9 100644
+--- a/drivers/pci/probe.c
++++ b/drivers/pci/probe.c
+@@ -1446,7 +1446,7 @@ int pci_setup_device(struct pci_dev *dev)
+ /* device class may be changed after fixup */
+ class = dev->class >> 8;
+
+- if (dev->non_compliant_bars) {
++ if (dev->non_compliant_bars && !dev->mmio_always_on) {
+ pci_read_config_word(dev, PCI_COMMAND, &cmd);
+ if (cmd & (PCI_COMMAND_IO | PCI_COMMAND_MEMORY)) {
+ dev_info(&dev->dev, "device has non-compliant BARs; disabling IO/MEM decoding\n");
+--
+2.25.1
+
--- /dev/null
+From f9df79371cf41df678b8b684cd24035bf42108c0 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 15 May 2020 16:27:04 +0300
+Subject: platform/x86: hp-wmi: Convert simple_strtoul() to kstrtou32()
+
+From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
+
+[ Upstream commit 5cdc45ed3948042f0d73c6fec5ee9b59e637d0d2 ]
+
+First of all, unsigned long can overflow u32 value on 64-bit machine.
+Second, simple_strtoul() doesn't check for overflow in the input.
+
+Convert simple_strtoul() to kstrtou32() to eliminate above issues.
+
+Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/platform/x86/hp-wmi.c | 10 ++++++++--
+ 1 file changed, 8 insertions(+), 2 deletions(-)
+
+diff --git a/drivers/platform/x86/hp-wmi.c b/drivers/platform/x86/hp-wmi.c
+index 06a3c1ef8eee..952544ca0d84 100644
+--- a/drivers/platform/x86/hp-wmi.c
++++ b/drivers/platform/x86/hp-wmi.c
+@@ -474,8 +474,14 @@ static ssize_t postcode_show(struct device *dev, struct device_attribute *attr,
+ static ssize_t als_store(struct device *dev, struct device_attribute *attr,
+ const char *buf, size_t count)
+ {
+- u32 tmp = simple_strtoul(buf, NULL, 10);
+- int ret = hp_wmi_perform_query(HPWMI_ALS_QUERY, HPWMI_WRITE, &tmp,
++ u32 tmp;
++ int ret;
++
++ ret = kstrtou32(buf, 10, &tmp);
++ if (ret)
++ return ret;
++
++ ret = hp_wmi_perform_query(HPWMI_ALS_QUERY, HPWMI_WRITE, &tmp,
+ sizeof(tmp), sizeof(tmp));
+ if (ret)
+ return ret < 0 ? ret : -EINVAL;
+--
+2.25.1
+
--- /dev/null
+From ff0b17783f53daa50fc5954a27894c90034f6951 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 5 May 2020 12:12:50 +0200
+Subject: powerpc/spufs: fix copy_to_user while atomic
+
+From: Jeremy Kerr <jk@ozlabs.org>
+
+[ Upstream commit 88413a6bfbbe2f648df399b62f85c934460b7a4d ]
+
+Currently, we may perform a copy_to_user (through
+simple_read_from_buffer()) while holding a context's register_lock,
+while accessing the context save area.
+
+This change uses a temporary buffer for the context save area data,
+which we then pass to simple_read_from_buffer.
+
+Includes changes from Christoph Hellwig <hch@lst.de>.
+
+Fixes: bf1ab978be23 ("[POWERPC] coredump: Add SPU elf notes to coredump.")
+Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
+Reviewed-by: Arnd Bergmann <arnd@arndb.de>
+[hch: renamed to function to avoid ___-prefixes]
+Signed-off-by: Christoph Hellwig <hch@lst.de>
+Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ arch/powerpc/platforms/cell/spufs/file.c | 113 +++++++++++++++--------
+ 1 file changed, 75 insertions(+), 38 deletions(-)
+
+diff --git a/arch/powerpc/platforms/cell/spufs/file.c b/arch/powerpc/platforms/cell/spufs/file.c
+index 5ffcdeb1eb17..9d9fffaedeef 100644
+--- a/arch/powerpc/platforms/cell/spufs/file.c
++++ b/arch/powerpc/platforms/cell/spufs/file.c
+@@ -1988,8 +1988,9 @@ static ssize_t __spufs_mbox_info_read(struct spu_context *ctx,
+ static ssize_t spufs_mbox_info_read(struct file *file, char __user *buf,
+ size_t len, loff_t *pos)
+ {
+- int ret;
+ struct spu_context *ctx = file->private_data;
++ u32 stat, data;
++ int ret;
+
+ if (!access_ok(VERIFY_WRITE, buf, len))
+ return -EFAULT;
+@@ -1998,11 +1999,16 @@ static ssize_t spufs_mbox_info_read(struct file *file, char __user *buf,
+ if (ret)
+ return ret;
+ spin_lock(&ctx->csa.register_lock);
+- ret = __spufs_mbox_info_read(ctx, buf, len, pos);
++ stat = ctx->csa.prob.mb_stat_R;
++ data = ctx->csa.prob.pu_mb_R;
+ spin_unlock(&ctx->csa.register_lock);
+ spu_release_saved(ctx);
+
+- return ret;
++ /* EOF if there's no entry in the mbox */
++ if (!(stat & 0x0000ff))
++ return 0;
++
++ return simple_read_from_buffer(buf, len, pos, &data, sizeof(data));
+ }
+
+ static const struct file_operations spufs_mbox_info_fops = {
+@@ -2029,6 +2035,7 @@ static ssize_t spufs_ibox_info_read(struct file *file, char __user *buf,
+ size_t len, loff_t *pos)
+ {
+ struct spu_context *ctx = file->private_data;
++ u32 stat, data;
+ int ret;
+
+ if (!access_ok(VERIFY_WRITE, buf, len))
+@@ -2038,11 +2045,16 @@ static ssize_t spufs_ibox_info_read(struct file *file, char __user *buf,
+ if (ret)
+ return ret;
+ spin_lock(&ctx->csa.register_lock);
+- ret = __spufs_ibox_info_read(ctx, buf, len, pos);
++ stat = ctx->csa.prob.mb_stat_R;
++ data = ctx->csa.priv2.puint_mb_R;
+ spin_unlock(&ctx->csa.register_lock);
+ spu_release_saved(ctx);
+
+- return ret;
++ /* EOF if there's no entry in the ibox */
++ if (!(stat & 0xff0000))
++ return 0;
++
++ return simple_read_from_buffer(buf, len, pos, &data, sizeof(data));
+ }
+
+ static const struct file_operations spufs_ibox_info_fops = {
+@@ -2051,6 +2063,11 @@ static const struct file_operations spufs_ibox_info_fops = {
+ .llseek = generic_file_llseek,
+ };
+
++static size_t spufs_wbox_info_cnt(struct spu_context *ctx)
++{
++ return (4 - ((ctx->csa.prob.mb_stat_R & 0x00ff00) >> 8)) * sizeof(u32);
++}
++
+ static ssize_t __spufs_wbox_info_read(struct spu_context *ctx,
+ char __user *buf, size_t len, loff_t *pos)
+ {
+@@ -2059,7 +2076,7 @@ static ssize_t __spufs_wbox_info_read(struct spu_context *ctx,
+ u32 wbox_stat;
+
+ wbox_stat = ctx->csa.prob.mb_stat_R;
+- cnt = 4 - ((wbox_stat & 0x00ff00) >> 8);
++ cnt = spufs_wbox_info_cnt(ctx);
+ for (i = 0; i < cnt; i++) {
+ data[i] = ctx->csa.spu_mailbox_data[i];
+ }
+@@ -2072,7 +2089,8 @@ static ssize_t spufs_wbox_info_read(struct file *file, char __user *buf,
+ size_t len, loff_t *pos)
+ {
+ struct spu_context *ctx = file->private_data;
+- int ret;
++ u32 data[ARRAY_SIZE(ctx->csa.spu_mailbox_data)];
++ int ret, count;
+
+ if (!access_ok(VERIFY_WRITE, buf, len))
+ return -EFAULT;
+@@ -2081,11 +2099,13 @@ static ssize_t spufs_wbox_info_read(struct file *file, char __user *buf,
+ if (ret)
+ return ret;
+ spin_lock(&ctx->csa.register_lock);
+- ret = __spufs_wbox_info_read(ctx, buf, len, pos);
++ count = spufs_wbox_info_cnt(ctx);
++ memcpy(&data, &ctx->csa.spu_mailbox_data, sizeof(data));
+ spin_unlock(&ctx->csa.register_lock);
+ spu_release_saved(ctx);
+
+- return ret;
++ return simple_read_from_buffer(buf, len, pos, &data,
++ count * sizeof(u32));
+ }
+
+ static const struct file_operations spufs_wbox_info_fops = {
+@@ -2094,27 +2114,33 @@ static const struct file_operations spufs_wbox_info_fops = {
+ .llseek = generic_file_llseek,
+ };
+
+-static ssize_t __spufs_dma_info_read(struct spu_context *ctx,
+- char __user *buf, size_t len, loff_t *pos)
++static void spufs_get_dma_info(struct spu_context *ctx,
++ struct spu_dma_info *info)
+ {
+- struct spu_dma_info info;
+- struct mfc_cq_sr *qp, *spuqp;
+ int i;
+
+- info.dma_info_type = ctx->csa.priv2.spu_tag_status_query_RW;
+- info.dma_info_mask = ctx->csa.lscsa->tag_mask.slot[0];
+- info.dma_info_status = ctx->csa.spu_chnldata_RW[24];
+- info.dma_info_stall_and_notify = ctx->csa.spu_chnldata_RW[25];
+- info.dma_info_atomic_command_status = ctx->csa.spu_chnldata_RW[27];
++ info->dma_info_type = ctx->csa.priv2.spu_tag_status_query_RW;
++ info->dma_info_mask = ctx->csa.lscsa->tag_mask.slot[0];
++ info->dma_info_status = ctx->csa.spu_chnldata_RW[24];
++ info->dma_info_stall_and_notify = ctx->csa.spu_chnldata_RW[25];
++ info->dma_info_atomic_command_status = ctx->csa.spu_chnldata_RW[27];
+ for (i = 0; i < 16; i++) {
+- qp = &info.dma_info_command_data[i];
+- spuqp = &ctx->csa.priv2.spuq[i];
++ struct mfc_cq_sr *qp = &info->dma_info_command_data[i];
++ struct mfc_cq_sr *spuqp = &ctx->csa.priv2.spuq[i];
+
+ qp->mfc_cq_data0_RW = spuqp->mfc_cq_data0_RW;
+ qp->mfc_cq_data1_RW = spuqp->mfc_cq_data1_RW;
+ qp->mfc_cq_data2_RW = spuqp->mfc_cq_data2_RW;
+ qp->mfc_cq_data3_RW = spuqp->mfc_cq_data3_RW;
+ }
++}
++
++static ssize_t __spufs_dma_info_read(struct spu_context *ctx,
++ char __user *buf, size_t len, loff_t *pos)
++{
++ struct spu_dma_info info;
++
++ spufs_get_dma_info(ctx, &info);
+
+ return simple_read_from_buffer(buf, len, pos, &info,
+ sizeof info);
+@@ -2124,6 +2150,7 @@ static ssize_t spufs_dma_info_read(struct file *file, char __user *buf,
+ size_t len, loff_t *pos)
+ {
+ struct spu_context *ctx = file->private_data;
++ struct spu_dma_info info;
+ int ret;
+
+ if (!access_ok(VERIFY_WRITE, buf, len))
+@@ -2133,11 +2160,12 @@ static ssize_t spufs_dma_info_read(struct file *file, char __user *buf,
+ if (ret)
+ return ret;
+ spin_lock(&ctx->csa.register_lock);
+- ret = __spufs_dma_info_read(ctx, buf, len, pos);
++ spufs_get_dma_info(ctx, &info);
+ spin_unlock(&ctx->csa.register_lock);
+ spu_release_saved(ctx);
+
+- return ret;
++ return simple_read_from_buffer(buf, len, pos, &info,
++ sizeof(info));
+ }
+
+ static const struct file_operations spufs_dma_info_fops = {
+@@ -2146,13 +2174,31 @@ static const struct file_operations spufs_dma_info_fops = {
+ .llseek = no_llseek,
+ };
+
++static void spufs_get_proxydma_info(struct spu_context *ctx,
++ struct spu_proxydma_info *info)
++{
++ int i;
++
++ info->proxydma_info_type = ctx->csa.prob.dma_querytype_RW;
++ info->proxydma_info_mask = ctx->csa.prob.dma_querymask_RW;
++ info->proxydma_info_status = ctx->csa.prob.dma_tagstatus_R;
++
++ for (i = 0; i < 8; i++) {
++ struct mfc_cq_sr *qp = &info->proxydma_info_command_data[i];
++ struct mfc_cq_sr *puqp = &ctx->csa.priv2.puq[i];
++
++ qp->mfc_cq_data0_RW = puqp->mfc_cq_data0_RW;
++ qp->mfc_cq_data1_RW = puqp->mfc_cq_data1_RW;
++ qp->mfc_cq_data2_RW = puqp->mfc_cq_data2_RW;
++ qp->mfc_cq_data3_RW = puqp->mfc_cq_data3_RW;
++ }
++}
++
+ static ssize_t __spufs_proxydma_info_read(struct spu_context *ctx,
+ char __user *buf, size_t len, loff_t *pos)
+ {
+ struct spu_proxydma_info info;
+- struct mfc_cq_sr *qp, *puqp;
+ int ret = sizeof info;
+- int i;
+
+ if (len < ret)
+ return -EINVAL;
+@@ -2160,18 +2206,7 @@ static ssize_t __spufs_proxydma_info_read(struct spu_context *ctx,
+ if (!access_ok(VERIFY_WRITE, buf, len))
+ return -EFAULT;
+
+- info.proxydma_info_type = ctx->csa.prob.dma_querytype_RW;
+- info.proxydma_info_mask = ctx->csa.prob.dma_querymask_RW;
+- info.proxydma_info_status = ctx->csa.prob.dma_tagstatus_R;
+- for (i = 0; i < 8; i++) {
+- qp = &info.proxydma_info_command_data[i];
+- puqp = &ctx->csa.priv2.puq[i];
+-
+- qp->mfc_cq_data0_RW = puqp->mfc_cq_data0_RW;
+- qp->mfc_cq_data1_RW = puqp->mfc_cq_data1_RW;
+- qp->mfc_cq_data2_RW = puqp->mfc_cq_data2_RW;
+- qp->mfc_cq_data3_RW = puqp->mfc_cq_data3_RW;
+- }
++ spufs_get_proxydma_info(ctx, &info);
+
+ return simple_read_from_buffer(buf, len, pos, &info,
+ sizeof info);
+@@ -2181,17 +2216,19 @@ static ssize_t spufs_proxydma_info_read(struct file *file, char __user *buf,
+ size_t len, loff_t *pos)
+ {
+ struct spu_context *ctx = file->private_data;
++ struct spu_proxydma_info info;
+ int ret;
+
+ ret = spu_acquire_saved(ctx);
+ if (ret)
+ return ret;
+ spin_lock(&ctx->csa.register_lock);
+- ret = __spufs_proxydma_info_read(ctx, buf, len, pos);
++ spufs_get_proxydma_info(ctx, &info);
+ spin_unlock(&ctx->csa.register_lock);
+ spu_release_saved(ctx);
+
+- return ret;
++ return simple_read_from_buffer(buf, len, pos, &info,
++ sizeof(info));
+ }
+
+ static const struct file_operations spufs_proxydma_info_fops = {
+--
+2.25.1
+
--- /dev/null
+From d585dfcaec34c899ba9a44d8464b12aaecef9812 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 13 May 2020 12:39:51 +0300
+Subject: rtlwifi: Fix a double free in _rtl_usb_tx_urb_setup()
+
+From: Dan Carpenter <dan.carpenter@oracle.com>
+
+[ Upstream commit beb12813bc75d4a23de43b85ad1c7cb28d27631e ]
+
+Seven years ago we tried to fix a leak but actually introduced a double
+free instead. It was an understandable mistake because the code was a
+bit confusing and the free was done in the wrong place. The "skb"
+pointer is freed in both _rtl_usb_tx_urb_setup() and _rtl_usb_transmit().
+The free belongs _rtl_usb_transmit() instead of _rtl_usb_tx_urb_setup()
+and I've cleaned the code up a bit to hopefully make it more clear.
+
+Fixes: 36ef0b473fbf ("rtlwifi: usb: add missing freeing of skbuff")
+Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
+Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
+Link: https://lore.kernel.org/r/20200513093951.GD347693@mwanda
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/wireless/realtek/rtlwifi/usb.c | 8 ++------
+ 1 file changed, 2 insertions(+), 6 deletions(-)
+
+diff --git a/drivers/net/wireless/realtek/rtlwifi/usb.c b/drivers/net/wireless/realtek/rtlwifi/usb.c
+index 93eda23f0123..7a050a75bdcb 100644
+--- a/drivers/net/wireless/realtek/rtlwifi/usb.c
++++ b/drivers/net/wireless/realtek/rtlwifi/usb.c
+@@ -910,10 +910,8 @@ static struct urb *_rtl_usb_tx_urb_setup(struct ieee80211_hw *hw,
+
+ WARN_ON(NULL == skb);
+ _urb = usb_alloc_urb(0, GFP_ATOMIC);
+- if (!_urb) {
+- kfree_skb(skb);
++ if (!_urb)
+ return NULL;
+- }
+ _rtl_install_trx_info(rtlusb, skb, ep_num);
+ usb_fill_bulk_urb(_urb, rtlusb->udev, usb_sndbulkpipe(rtlusb->udev,
+ ep_num), skb->data, skb->len, _rtl_tx_complete, skb);
+@@ -927,7 +925,6 @@ static void _rtl_usb_transmit(struct ieee80211_hw *hw, struct sk_buff *skb,
+ struct rtl_usb *rtlusb = rtl_usbdev(rtl_usbpriv(hw));
+ u32 ep_num;
+ struct urb *_urb = NULL;
+- struct sk_buff *_skb = NULL;
+
+ WARN_ON(NULL == rtlusb->usb_tx_aggregate_hdl);
+ if (unlikely(IS_USB_STOP(rtlusb))) {
+@@ -936,8 +933,7 @@ static void _rtl_usb_transmit(struct ieee80211_hw *hw, struct sk_buff *skb,
+ return;
+ }
+ ep_num = rtlusb->ep_map.ep_mapping[qnum];
+- _skb = skb;
+- _urb = _rtl_usb_tx_urb_setup(hw, _skb, ep_num);
++ _urb = _rtl_usb_tx_urb_setup(hw, skb, ep_num);
+ if (unlikely(!_urb)) {
+ pr_err("Can't allocate urb. Drop skb!\n");
+ kfree_skb(skb);
+--
+2.25.1
+
can-kvaser_usb-kvaser_usb_leaf-fix-some-info-leaks-to-usb-devices.patch
xen-pvcalls-back-test-for-errors-when-calling-backend_connect.patch
acpi-ged-use-correct-trigger-type-field-in-_exx-_lxx-handling.patch
+drm-bridge-adv7511-extend-list-of-audio-sample-rates.patch
+crypto-ccp-don-t-select-config_dmadevices.patch
+media-si2157-better-check-for-running-tuner-in-init.patch
+objtool-ignore-empty-alternatives.patch
+spi-pxa2xx-apply-cs-clk-quirk-to-bxt.patch
+net-ena-fix-error-returning-in-ena_com_get_hash_func.patch
+spi-dw-zero-dma-tx-and-rx-configurations-on-stack.patch
+ixgbe-fix-xdp-redirect-on-archs-with-page_size-above.patch
+mips-loongson-build-ati-radeon-gpu-driver-as-module.patch
+bluetooth-add-sco-fallback-for-invalid-lmp-parameter.patch
+kgdb-prevent-infinite-recursive-entries-to-the-debug.patch
+spi-dw-enable-interrupts-in-accordance-with-dma-xfer.patch
+clocksource-dw_apb_timer-make-cpu-affiliation-being-.patch
+clocksource-dw_apb_timer_of-fix-missing-clockevent-t.patch
+btrfs-do-not-ignore-error-from-btrfs_next_leaf-when-.patch
+arm-8978-1-mm-make-act_mm-respect-thread_size.patch
+spi-dw-fix-rx-only-dma-transfers.patch
+x86-kvm-hyper-v-explicitly-align-hcall-param-for-kvm.patch
+net-vmxnet3-fix-possible-buffer-overflow-caused-by-b.patch
+staging-android-ion-use-vmap-instead-of-vm_map_ram.patch
+brcmfmac-fix-wrong-location-to-get-firmware-feature.patch
+tools-api-fs-make-xxx__mountpoint-more-scalable.patch
+e1000-distribute-switch-variables-for-initialization.patch
+dt-bindings-display-mediatek-control-dpi-pins-mode-t.patch
+audit-fix-a-net-reference-leak-in-audit_send_reply.patch
+media-dvb-return-eremoteio-on-i2c-transfer-failure.patch
+media-platform-fcp-set-appropriate-dma-parameters.patch
+mips-make-sparse_init-using-top-down-allocation.patch
+audit-fix-a-net-reference-leak-in-audit_list_rules_s.patch
+netfilter-nft_nat-return-eopnotsupp-if-type-or-flags.patch
+net-bcmgenet-set-rx-mode-before-starting-netif.patch
+lib-mpi-fix-64-bit-mips-build-with-clang.patch
+exit-move-preemption-fixup-up-move-blocking-operatio.patch
+net-lpc-enet-fix-error-return-code-in-lpc_mii_init.patch
+media-cec-silence-shift-wrapping-warning-in-__cec_s_.patch
+net-allwinner-fix-use-correct-return-type-for-ndo_st.patch
+powerpc-spufs-fix-copy_to_user-while-atomic.patch
+crypto-chcr-fix-for-ccm-aes-failed-test.patch
+mips-truncate-link-address-into-32bit-for-32bit-kern.patch
+mips-cm-fix-an-invalid-error-code-of-intvn_-_err.patch
+kgdb-fix-spurious-true-from-in_dbg_master.patch
+nvme-refine-the-qemu-identify-cns-quirk.patch
+wcn36xx-fix-error-handling-path-in-wcn36xx_probe.patch
+net-qed-reduce-rx-and-tx-default-ring-count-when-run.patch
+md-don-t-flush-workqueue-unconditionally-in-md_open.patch
+rtlwifi-fix-a-double-free-in-_rtl_usb_tx_urb_setup.patch
+mwifiex-fix-memory-corruption-in-dump_station.patch
+x86-boot-correct-relocation-destination-on-old-linke.patch
+mips-maar-use-more-precise-address-mask.patch
+mips-add-udelay-lpj-numbers-adjustment.patch
+x86-mm-stop-printing-brk-addresses.patch
+m68k-mac-don-t-call-via_flush_cache-on-mac-iifx.patch
+macvlan-skip-loopback-packets-in-rx-handler.patch
+pci-don-t-disable-decoding-when-mmio_always_on-is-se.patch
+mips-fix-irq-tracing-when-call-handle_fpe-and-handle.patch
+mmc-sdhci-msm-set-sdhci_quirk_multiblock_read_acmd12.patch
+staging-greybus-sdio-respect-the-cmd-busy_timeout-fr.patch
+mmc-via-sdmmc-respect-the-cmd-busy_timeout-from-the-.patch
+ixgbe-fix-signed-integer-overflow-warning.patch
+mmc-sdhci-esdhc-imx-fix-the-mask-for-tuning-start-po.patch
+spi-dw-return-any-value-retrieved-from-the-dma_trans.patch
+cpuidle-fix-three-reference-count-leaks.patch
+platform-x86-hp-wmi-convert-simple_strtoul-to-kstrto.patch
+string.h-fix-incompatibility-between-fortify_source-.patch
--- /dev/null
+From 568c2277b0055c59dd1ed91a8ed524affdde16e8 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 22 May 2020 03:07:51 +0300
+Subject: spi: dw: Enable interrupts in accordance with DMA xfer mode
+
+From: Serge Semin <Sergey.Semin@baikalelectronics.ru>
+
+[ Upstream commit 43dba9f3f98c2b184a19f856f06fe22817bfd9e0 ]
+
+It's pointless to track the Tx overrun interrupts if Rx-only SPI
+transfer is issued. Similarly there is no need in handling the Rx
+overrun/underrun interrupts if Tx-only SPI transfer is executed.
+So lets unmask the interrupts only if corresponding SPI
+transactions are implied.
+
+Co-developed-by: Georgy Vlasov <Georgy.Vlasov@baikalelectronics.ru>
+Signed-off-by: Georgy Vlasov <Georgy.Vlasov@baikalelectronics.ru>
+Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
+Cc: Ramil Zaripov <Ramil.Zaripov@baikalelectronics.ru>
+Cc: Alexey Malahov <Alexey.Malahov@baikalelectronics.ru>
+Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
+Cc: Paul Burton <paulburton@kernel.org>
+Cc: Ralf Baechle <ralf@linux-mips.org>
+Cc: Arnd Bergmann <arnd@arndb.de>
+Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
+Cc: Rob Herring <robh+dt@kernel.org>
+Cc: linux-mips@vger.kernel.org
+Cc: devicetree@vger.kernel.org
+Link: https://lore.kernel.org/r/20200522000806.7381-3-Sergey.Semin@baikalelectronics.ru
+Signed-off-by: Mark Brown <broonie@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/spi/spi-dw-mid.c | 12 ++++++++----
+ 1 file changed, 8 insertions(+), 4 deletions(-)
+
+diff --git a/drivers/spi/spi-dw-mid.c b/drivers/spi/spi-dw-mid.c
+index 4f41d44e8b4c..c4244d2f1ee3 100644
+--- a/drivers/spi/spi-dw-mid.c
++++ b/drivers/spi/spi-dw-mid.c
+@@ -228,19 +228,23 @@ static struct dma_async_tx_descriptor *dw_spi_dma_prepare_rx(struct dw_spi *dws,
+
+ static int mid_spi_dma_setup(struct dw_spi *dws, struct spi_transfer *xfer)
+ {
+- u16 dma_ctrl = 0;
++ u16 imr = 0, dma_ctrl = 0;
+
+ dw_writel(dws, DW_SPI_DMARDLR, 0xf);
+ dw_writel(dws, DW_SPI_DMATDLR, 0x10);
+
+- if (xfer->tx_buf)
++ if (xfer->tx_buf) {
+ dma_ctrl |= SPI_DMA_TDMAE;
+- if (xfer->rx_buf)
++ imr |= SPI_INT_TXOI;
++ }
++ if (xfer->rx_buf) {
+ dma_ctrl |= SPI_DMA_RDMAE;
++ imr |= SPI_INT_RXUI | SPI_INT_RXOI;
++ }
+ dw_writel(dws, DW_SPI_DMACR, dma_ctrl);
+
+ /* Set the interrupt mask */
+- spi_umask_intr(dws, SPI_INT_TXOI | SPI_INT_RXUI | SPI_INT_RXOI);
++ spi_umask_intr(dws, imr);
+
+ dws->transfer_handler = dma_transfer;
+
+--
+2.25.1
+
--- /dev/null
+From 5e706898a186a908870a9f53f6001ab16746ff4d Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 29 May 2020 16:11:57 +0300
+Subject: spi: dw: Fix Rx-only DMA transfers
+
+From: Serge Semin <Sergey.Semin@baikalelectronics.ru>
+
+[ Upstream commit 46164fde6b7890e7a3982d54549947c8394c0192 ]
+
+Tx-only DMA transfers are working perfectly fine since in this case
+the code just ignores the Rx FIFO overflow interrupts. But it turns
+out the SPI Rx-only transfers are broken since nothing pushing any
+data to the shift registers, so the Rx FIFO is left empty and the
+SPI core subsystems just returns a timeout error. Since DW DMAC
+driver doesn't support something like cyclic write operations of
+a single byte to a device register, the only way to support the
+Rx-only SPI transfers is to fake it by using a dummy Tx-buffer.
+This is what we intend to fix in this commit by setting the
+SPI_CONTROLLER_MUST_TX flag for DMA-capable platform.
+
+Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
+Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
+Cc: Georgy Vlasov <Georgy.Vlasov@baikalelectronics.ru>
+Cc: Ramil Zaripov <Ramil.Zaripov@baikalelectronics.ru>
+Cc: Alexey Malahov <Alexey.Malahov@baikalelectronics.ru>
+Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
+Cc: Arnd Bergmann <arnd@arndb.de>
+Cc: Feng Tang <feng.tang@intel.com>
+Cc: Rob Herring <robh+dt@kernel.org>
+Cc: linux-mips@vger.kernel.org
+Cc: devicetree@vger.kernel.org
+Link: https://lore.kernel.org/r/20200529131205.31838-9-Sergey.Semin@baikalelectronics.ru
+Signed-off-by: Mark Brown <broonie@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/spi/spi-dw.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/drivers/spi/spi-dw.c b/drivers/spi/spi-dw.c
+index b11d0cd3fd20..9fcee7273a79 100644
+--- a/drivers/spi/spi-dw.c
++++ b/drivers/spi/spi-dw.c
+@@ -531,6 +531,7 @@ int dw_spi_add_host(struct device *dev, struct dw_spi *dws)
+ dws->dma_inited = 0;
+ } else {
+ master->can_dma = dws->dma_ops->can_dma;
++ master->flags |= SPI_CONTROLLER_MUST_TX;
+ }
+ }
+
+--
+2.25.1
+
--- /dev/null
+From 2bdfd677c63afe79ee0a57120bfa62d643b7dcb9 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 29 May 2020 16:11:51 +0300
+Subject: spi: dw: Return any value retrieved from the dma_transfer callback
+
+From: Serge Semin <Sergey.Semin@baikalelectronics.ru>
+
+[ Upstream commit f0410bbf7d0fb80149e3b17d11d31f5b5197873e ]
+
+DW APB SSI DMA-part of the driver may need to perform the requested
+SPI-transfer synchronously. In that case the dma_transfer() callback
+will return 0 as a marker of the SPI transfer being finished so the
+SPI core doesn't need to wait and may proceed with the SPI message
+trasnfers pumping procedure. This will be needed to fix the problem
+when DMA transactions are finished, but there is still data left in
+the SPI Tx/Rx FIFOs being sent/received. But for now make dma_transfer
+to return 1 as the normal dw_spi_transfer_one() method.
+
+Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
+Cc: Georgy Vlasov <Georgy.Vlasov@baikalelectronics.ru>
+Cc: Ramil Zaripov <Ramil.Zaripov@baikalelectronics.ru>
+Cc: Alexey Malahov <Alexey.Malahov@baikalelectronics.ru>
+Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
+Cc: Arnd Bergmann <arnd@arndb.de>
+Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
+Cc: Feng Tang <feng.tang@intel.com>
+Cc: Rob Herring <robh+dt@kernel.org>
+Cc: linux-mips@vger.kernel.org
+Cc: devicetree@vger.kernel.org
+Link: https://lore.kernel.org/r/20200529131205.31838-3-Sergey.Semin@baikalelectronics.ru
+Signed-off-by: Mark Brown <broonie@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/spi/spi-dw-mid.c | 2 +-
+ drivers/spi/spi-dw.c | 7 ++-----
+ 2 files changed, 3 insertions(+), 6 deletions(-)
+
+diff --git a/drivers/spi/spi-dw-mid.c b/drivers/spi/spi-dw-mid.c
+index c4244d2f1ee3..cb268cc4ba2b 100644
+--- a/drivers/spi/spi-dw-mid.c
++++ b/drivers/spi/spi-dw-mid.c
+@@ -274,7 +274,7 @@ static int mid_spi_dma_transfer(struct dw_spi *dws, struct spi_transfer *xfer)
+ dma_async_issue_pending(dws->txchan);
+ }
+
+- return 0;
++ return 1;
+ }
+
+ static void mid_spi_dma_stop(struct dw_spi *dws)
+diff --git a/drivers/spi/spi-dw.c b/drivers/spi/spi-dw.c
+index 9fcee7273a79..d2428a8809c1 100644
+--- a/drivers/spi/spi-dw.c
++++ b/drivers/spi/spi-dw.c
+@@ -384,11 +384,8 @@ static int dw_spi_transfer_one(struct spi_master *master,
+
+ spi_enable_chip(dws, 1);
+
+- if (dws->dma_mapped) {
+- ret = dws->dma_ops->dma_transfer(dws, transfer);
+- if (ret < 0)
+- return ret;
+- }
++ if (dws->dma_mapped)
++ return dws->dma_ops->dma_transfer(dws, transfer);
+
+ if (chip->poll_mode)
+ return poll_transfer(dws);
+--
+2.25.1
+
--- /dev/null
+From 234487b58c98734ddd227b809df73ca5a82903c2 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 6 May 2020 18:30:18 +0300
+Subject: spi: dw: Zero DMA Tx and Rx configurations on stack
+
+From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
+
+[ Upstream commit 3cb97e223d277f84171cc4ccecab31e08b2ee7b5 ]
+
+Some DMA controller drivers do not tolerate non-zero values in
+the DMA configuration structures. Zero them to avoid issues with
+such DMA controller drivers. Even despite above this is a good
+practice per se.
+
+Fixes: 7063c0d942a1 ("spi/dw_spi: add DMA support")
+Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
+Acked-by: Feng Tang <feng.tang@intel.com>
+Cc: Feng Tang <feng.tang@intel.com>
+Link: https://lore.kernel.org/r/20200506153025.21441-1-andriy.shevchenko@linux.intel.com
+Signed-off-by: Mark Brown <broonie@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/spi/spi-dw-mid.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+diff --git a/drivers/spi/spi-dw-mid.c b/drivers/spi/spi-dw-mid.c
+index 837cb8d0bac6..4f41d44e8b4c 100644
+--- a/drivers/spi/spi-dw-mid.c
++++ b/drivers/spi/spi-dw-mid.c
+@@ -155,6 +155,7 @@ static struct dma_async_tx_descriptor *dw_spi_dma_prepare_tx(struct dw_spi *dws,
+ if (!xfer->tx_buf)
+ return NULL;
+
++ memset(&txconf, 0, sizeof(txconf));
+ txconf.direction = DMA_MEM_TO_DEV;
+ txconf.dst_addr = dws->dma_addr;
+ txconf.dst_maxburst = 16;
+@@ -201,6 +202,7 @@ static struct dma_async_tx_descriptor *dw_spi_dma_prepare_rx(struct dw_spi *dws,
+ if (!xfer->rx_buf)
+ return NULL;
+
++ memset(&rxconf, 0, sizeof(rxconf));
+ rxconf.direction = DMA_DEV_TO_MEM;
+ rxconf.src_addr = dws->dma_addr;
+ rxconf.src_maxburst = 16;
+--
+2.25.1
+
--- /dev/null
+From bfc010f91dc978ea1140094a9b76cdb2d5bfe890 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Mon, 27 Apr 2020 16:32:48 -0700
+Subject: spi: pxa2xx: Apply CS clk quirk to BXT
+
+From: Evan Green <evgreen@chromium.org>
+
+[ Upstream commit 6eefaee4f2d366a389da0eb95e524ba82bf358c4 ]
+
+With a couple allies at Intel, and much badgering, I got confirmation
+from Intel that at least BXT suffers from the same SPI chip-select
+issue as Cannonlake (and beyond). The issue being that after going
+through runtime suspend/resume, toggling the chip-select line without
+also sending data does nothing.
+
+Add the quirk to BXT to briefly toggle dynamic clock gating off and
+on, forcing the fabric to wake up enough to notice the CS register
+change.
+
+Signed-off-by: Evan Green <evgreen@chromium.org>
+Cc: Shobhit Srivastava <shobhit.srivastava@intel.com>
+Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
+Link: https://lore.kernel.org/r/20200427163238.1.Ib1faaabe236e37ea73be9b8dcc6aa034cb3c8804@changeid
+Signed-off-by: Mark Brown <broonie@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/spi/spi-pxa2xx.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/drivers/spi/spi-pxa2xx.c b/drivers/spi/spi-pxa2xx.c
+index b73fde1de463..1579eb2bc29f 100644
+--- a/drivers/spi/spi-pxa2xx.c
++++ b/drivers/spi/spi-pxa2xx.c
+@@ -156,6 +156,7 @@ static const struct lpss_config lpss_platforms[] = {
+ .tx_threshold_hi = 48,
+ .cs_sel_shift = 8,
+ .cs_sel_mask = 3 << 8,
++ .cs_clk_stays_gated = true,
+ },
+ { /* LPSS_CNL_SSP */
+ .offset = 0x200,
+--
+2.25.1
+
--- /dev/null
+From 53b1e7b61773cbce25eaa97d5f2edf52dcd8446a Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Mon, 1 Jun 2020 21:50:23 -0700
+Subject: staging: android: ion: use vmap instead of vm_map_ram
+
+From: Christoph Hellwig <hch@lst.de>
+
+[ Upstream commit 5bf9917452112694b2c774465ee4dbe441c84b77 ]
+
+vm_map_ram can keep mappings around after the vm_unmap_ram. Using that
+with non-PAGE_KERNEL mappings can lead to all kinds of aliasing issues.
+
+Signed-off-by: Christoph Hellwig <hch@lst.de>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
+Cc: Christian Borntraeger <borntraeger@de.ibm.com>
+Cc: Christophe Leroy <christophe.leroy@c-s.fr>
+Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
+Cc: David Airlie <airlied@linux.ie>
+Cc: Gao Xiang <xiang@kernel.org>
+Cc: Haiyang Zhang <haiyangz@microsoft.com>
+Cc: Johannes Weiner <hannes@cmpxchg.org>
+Cc: "K. Y. Srinivasan" <kys@microsoft.com>
+Cc: Laura Abbott <labbott@redhat.com>
+Cc: Mark Rutland <mark.rutland@arm.com>
+Cc: Michael Kelley <mikelley@microsoft.com>
+Cc: Minchan Kim <minchan@kernel.org>
+Cc: Nitin Gupta <ngupta@vflare.org>
+Cc: Robin Murphy <robin.murphy@arm.com>
+Cc: Sakari Ailus <sakari.ailus@linux.intel.com>
+Cc: Stephen Hemminger <sthemmin@microsoft.com>
+Cc: Sumit Semwal <sumit.semwal@linaro.org>
+Cc: Wei Liu <wei.liu@kernel.org>
+Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
+Cc: Catalin Marinas <catalin.marinas@arm.com>
+Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
+Cc: Paul Mackerras <paulus@ozlabs.org>
+Cc: Vasily Gorbik <gor@linux.ibm.com>
+Cc: Will Deacon <will@kernel.org>
+Link: http://lkml.kernel.org/r/20200414131348.444715-4-hch@lst.de
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/staging/android/ion/ion_heap.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/drivers/staging/android/ion/ion_heap.c b/drivers/staging/android/ion/ion_heap.c
+index babbd94c32d9..33a9777e7a99 100644
+--- a/drivers/staging/android/ion/ion_heap.c
++++ b/drivers/staging/android/ion/ion_heap.c
+@@ -105,12 +105,12 @@ int ion_heap_map_user(struct ion_heap *heap, struct ion_buffer *buffer,
+
+ static int ion_heap_clear_pages(struct page **pages, int num, pgprot_t pgprot)
+ {
+- void *addr = vm_map_ram(pages, num, -1, pgprot);
++ void *addr = vmap(pages, num, VM_MAP, pgprot);
+
+ if (!addr)
+ return -ENOMEM;
+ memset(addr, 0, PAGE_SIZE * num);
+- vm_unmap_ram(addr, num);
++ vunmap(addr);
+
+ return 0;
+ }
+--
+2.25.1
+
--- /dev/null
+From c892ad6cb0cae2d7b4a7763fe5b75b280a4ee181 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 14 Apr 2020 18:14:13 +0200
+Subject: staging: greybus: sdio: Respect the cmd->busy_timeout from the mmc
+ core
+
+From: Ulf Hansson <ulf.hansson@linaro.org>
+
+[ Upstream commit a389087ee9f195fcf2f31cd771e9ec5f02c16650 ]
+
+Using a fixed 1s timeout for all commands is a bit problematic.
+
+For some commands it means waiting longer than needed for the timeout to
+expire, which may not a big issue, but still. For other commands, like for
+an erase (CMD38) that uses a R1B response, may require longer timeouts than
+1s. In these cases, we may end up treating the command as it failed, while
+it just needed some more time to complete successfully.
+
+Fix the problem by respecting the cmd->busy_timeout, which is provided by
+the mmc core.
+
+Cc: Rui Miguel Silva <rmfrfs@gmail.com>
+Cc: Johan Hovold <johan@kernel.org>
+Cc: Alex Elder <elder@kernel.org>
+Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Cc: greybus-dev@lists.linaro.org
+Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
+Acked-by: Rui Miguel Silva <rmfrfs@gmail.com>
+Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Link: https://lore.kernel.org/r/20200414161413.3036-20-ulf.hansson@linaro.org
+Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/staging/greybus/sdio.c | 10 +++++++---
+ 1 file changed, 7 insertions(+), 3 deletions(-)
+
+diff --git a/drivers/staging/greybus/sdio.c b/drivers/staging/greybus/sdio.c
+index 101ca5097fc9..93e2c091c565 100644
+--- a/drivers/staging/greybus/sdio.c
++++ b/drivers/staging/greybus/sdio.c
+@@ -412,6 +412,7 @@ static int gb_sdio_command(struct gb_sdio_host *host, struct mmc_command *cmd)
+ struct gb_sdio_command_request request = {0};
+ struct gb_sdio_command_response response;
+ struct mmc_data *data = host->mrq->data;
++ unsigned int timeout_ms;
+ u8 cmd_flags;
+ u8 cmd_type;
+ int i;
+@@ -470,9 +471,12 @@ static int gb_sdio_command(struct gb_sdio_host *host, struct mmc_command *cmd)
+ request.data_blksz = cpu_to_le16(data->blksz);
+ }
+
+- ret = gb_operation_sync(host->connection, GB_SDIO_TYPE_COMMAND,
+- &request, sizeof(request), &response,
+- sizeof(response));
++ timeout_ms = cmd->busy_timeout ? cmd->busy_timeout :
++ GB_OPERATION_TIMEOUT_DEFAULT;
++
++ ret = gb_operation_sync_timeout(host->connection, GB_SDIO_TYPE_COMMAND,
++ &request, sizeof(request), &response,
++ sizeof(response), timeout_ms);
+ if (ret < 0)
+ goto out;
+
+--
+2.25.1
+
--- /dev/null
+From 02f4e16daa97ce24aa670ac6fbda36bbec68c5bb Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 3 Jun 2020 15:56:46 -0700
+Subject: string.h: fix incompatibility between FORTIFY_SOURCE and KASAN
+
+From: Daniel Axtens <dja@axtens.net>
+
+[ Upstream commit 47227d27e2fcb01a9e8f5958d8997cf47a820afc ]
+
+The memcmp KASAN self-test fails on a kernel with both KASAN and
+FORTIFY_SOURCE.
+
+When FORTIFY_SOURCE is on, a number of functions are replaced with
+fortified versions, which attempt to check the sizes of the operands.
+However, these functions often directly invoke __builtin_foo() once they
+have performed the fortify check. Using __builtins may bypass KASAN
+checks if the compiler decides to inline it's own implementation as
+sequence of instructions, rather than emit a function call that goes out
+to a KASAN-instrumented implementation.
+
+Why is only memcmp affected?
+============================
+
+Of the string and string-like functions that kasan_test tests, only memcmp
+is replaced by an inline sequence of instructions in my testing on x86
+with gcc version 9.2.1 20191008 (Ubuntu 9.2.1-9ubuntu2).
+
+I believe this is due to compiler heuristics. For example, if I annotate
+kmalloc calls with the alloc_size annotation (and disable some fortify
+compile-time checking!), the compiler will replace every memset except the
+one in kmalloc_uaf_memset with inline instructions. (I have some WIP
+patches to add this annotation.)
+
+Does this affect other functions in string.h?
+=============================================
+
+Yes. Anything that uses __builtin_* rather than __real_* could be
+affected. This looks like:
+
+ - strncpy
+ - strcat
+ - strlen
+ - strlcpy maybe, under some circumstances?
+ - strncat under some circumstances
+ - memset
+ - memcpy
+ - memmove
+ - memcmp (as noted)
+ - memchr
+ - strcpy
+
+Whether a function call is emitted always depends on the compiler. Most
+bugs should get caught by FORTIFY_SOURCE, but the missed memcmp test shows
+that this is not always the case.
+
+Isn't FORTIFY_SOURCE disabled with KASAN?
+========================================-
+
+The string headers on all arches supporting KASAN disable fortify with
+kasan, but only when address sanitisation is _also_ disabled. For example
+from x86:
+
+ #if defined(CONFIG_KASAN) && !defined(__SANITIZE_ADDRESS__)
+ /*
+ * For files that are not instrumented (e.g. mm/slub.c) we
+ * should use not instrumented version of mem* functions.
+ */
+ #define memcpy(dst, src, len) __memcpy(dst, src, len)
+ #define memmove(dst, src, len) __memmove(dst, src, len)
+ #define memset(s, c, n) __memset(s, c, n)
+
+ #ifndef __NO_FORTIFY
+ #define __NO_FORTIFY /* FORTIFY_SOURCE uses __builtin_memcpy, etc. */
+ #endif
+
+ #endif
+
+This comes from commit 6974f0c4555e ("include/linux/string.h: add the
+option of fortified string.h functions"), and doesn't work when KASAN is
+enabled and the file is supposed to be sanitised - as with test_kasan.c
+
+I'm pretty sure this is not wrong, but not as expansive it should be:
+
+ * we shouldn't use __builtin_memcpy etc in files where we don't have
+ instrumentation - it could devolve into a function call to memcpy,
+ which will be instrumented. Rather, we should use __memcpy which
+ by convention is not instrumented.
+
+ * we also shouldn't be using __builtin_memcpy when we have a KASAN
+ instrumented file, because it could be replaced with inline asm
+ that will not be instrumented.
+
+What is correct behaviour?
+==========================
+
+Firstly, there is some overlap between fortification and KASAN: both
+provide some level of _runtime_ checking. Only fortify provides
+compile-time checking.
+
+KASAN and fortify can pick up different things at runtime:
+
+ - Some fortify functions, notably the string functions, could easily be
+ modified to consider sub-object sizes (e.g. members within a struct),
+ and I have some WIP patches to do this. KASAN cannot detect these
+ because it cannot insert poision between members of a struct.
+
+ - KASAN can detect many over-reads/over-writes when the sizes of both
+ operands are unknown, which fortify cannot.
+
+So there are a couple of options:
+
+ 1) Flip the test: disable fortify in santised files and enable it in
+ unsanitised files. This at least stops us missing KASAN checking, but
+ we lose the fortify checking.
+
+ 2) Make the fortify code always call out to real versions. Do this only
+ for KASAN, for fear of losing the inlining opportunities we get from
+ __builtin_*.
+
+(We can't use kasan_check_{read,write}: because the fortify functions are
+_extern inline_, you can't include _static_ inline functions without a
+compiler warning. kasan_check_{read,write} are static inline so we can't
+use them even when they would otherwise be suitable.)
+
+Take approach 2 and call out to real versions when KASAN is enabled.
+
+Use __underlying_foo to distinguish from __real_foo: __real_foo always
+refers to the kernel's implementation of foo, __underlying_foo could be
+either the kernel implementation or the __builtin_foo implementation.
+
+This is sometimes enough to make the memcmp test succeed with
+FORTIFY_SOURCE enabled. It is at least enough to get the function call
+into the module. One more fix is needed to make it reliable: see the next
+patch.
+
+Fixes: 6974f0c4555e ("include/linux/string.h: add the option of fortified string.h functions")
+Signed-off-by: Daniel Axtens <dja@axtens.net>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Tested-by: David Gow <davidgow@google.com>
+Reviewed-by: Dmitry Vyukov <dvyukov@google.com>
+Cc: Daniel Micay <danielmicay@gmail.com>
+Cc: Andrey Ryabinin <aryabinin@virtuozzo.com>
+Cc: Alexander Potapenko <glider@google.com>
+Link: http://lkml.kernel.org/r/20200423154503.5103-3-dja@axtens.net
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ include/linux/string.h | 60 +++++++++++++++++++++++++++++++++---------
+ 1 file changed, 48 insertions(+), 12 deletions(-)
+
+diff --git a/include/linux/string.h b/include/linux/string.h
+index 3d43329c20be..315fef3aff4e 100644
+--- a/include/linux/string.h
++++ b/include/linux/string.h
+@@ -238,6 +238,31 @@ void __read_overflow3(void) __compiletime_error("detected read beyond size of ob
+ void __write_overflow(void) __compiletime_error("detected write beyond size of object passed as 1st parameter");
+
+ #if !defined(__NO_FORTIFY) && defined(__OPTIMIZE__) && defined(CONFIG_FORTIFY_SOURCE)
++
++#ifdef CONFIG_KASAN
++extern void *__underlying_memchr(const void *p, int c, __kernel_size_t size) __RENAME(memchr);
++extern int __underlying_memcmp(const void *p, const void *q, __kernel_size_t size) __RENAME(memcmp);
++extern void *__underlying_memcpy(void *p, const void *q, __kernel_size_t size) __RENAME(memcpy);
++extern void *__underlying_memmove(void *p, const void *q, __kernel_size_t size) __RENAME(memmove);
++extern void *__underlying_memset(void *p, int c, __kernel_size_t size) __RENAME(memset);
++extern char *__underlying_strcat(char *p, const char *q) __RENAME(strcat);
++extern char *__underlying_strcpy(char *p, const char *q) __RENAME(strcpy);
++extern __kernel_size_t __underlying_strlen(const char *p) __RENAME(strlen);
++extern char *__underlying_strncat(char *p, const char *q, __kernel_size_t count) __RENAME(strncat);
++extern char *__underlying_strncpy(char *p, const char *q, __kernel_size_t size) __RENAME(strncpy);
++#else
++#define __underlying_memchr __builtin_memchr
++#define __underlying_memcmp __builtin_memcmp
++#define __underlying_memcpy __builtin_memcpy
++#define __underlying_memmove __builtin_memmove
++#define __underlying_memset __builtin_memset
++#define __underlying_strcat __builtin_strcat
++#define __underlying_strcpy __builtin_strcpy
++#define __underlying_strlen __builtin_strlen
++#define __underlying_strncat __builtin_strncat
++#define __underlying_strncpy __builtin_strncpy
++#endif
++
+ __FORTIFY_INLINE char *strncpy(char *p, const char *q, __kernel_size_t size)
+ {
+ size_t p_size = __builtin_object_size(p, 0);
+@@ -245,14 +270,14 @@ __FORTIFY_INLINE char *strncpy(char *p, const char *q, __kernel_size_t size)
+ __write_overflow();
+ if (p_size < size)
+ fortify_panic(__func__);
+- return __builtin_strncpy(p, q, size);
++ return __underlying_strncpy(p, q, size);
+ }
+
+ __FORTIFY_INLINE char *strcat(char *p, const char *q)
+ {
+ size_t p_size = __builtin_object_size(p, 0);
+ if (p_size == (size_t)-1)
+- return __builtin_strcat(p, q);
++ return __underlying_strcat(p, q);
+ if (strlcat(p, q, p_size) >= p_size)
+ fortify_panic(__func__);
+ return p;
+@@ -266,7 +291,7 @@ __FORTIFY_INLINE __kernel_size_t strlen(const char *p)
+ /* Work around gcc excess stack consumption issue */
+ if (p_size == (size_t)-1 ||
+ (__builtin_constant_p(p[p_size - 1]) && p[p_size - 1] == '\0'))
+- return __builtin_strlen(p);
++ return __underlying_strlen(p);
+ ret = strnlen(p, p_size);
+ if (p_size <= ret)
+ fortify_panic(__func__);
+@@ -299,7 +324,7 @@ __FORTIFY_INLINE size_t strlcpy(char *p, const char *q, size_t size)
+ __write_overflow();
+ if (len >= p_size)
+ fortify_panic(__func__);
+- __builtin_memcpy(p, q, len);
++ __underlying_memcpy(p, q, len);
+ p[len] = '\0';
+ }
+ return ret;
+@@ -312,12 +337,12 @@ __FORTIFY_INLINE char *strncat(char *p, const char *q, __kernel_size_t count)
+ size_t p_size = __builtin_object_size(p, 0);
+ size_t q_size = __builtin_object_size(q, 0);
+ if (p_size == (size_t)-1 && q_size == (size_t)-1)
+- return __builtin_strncat(p, q, count);
++ return __underlying_strncat(p, q, count);
+ p_len = strlen(p);
+ copy_len = strnlen(q, count);
+ if (p_size < p_len + copy_len + 1)
+ fortify_panic(__func__);
+- __builtin_memcpy(p + p_len, q, copy_len);
++ __underlying_memcpy(p + p_len, q, copy_len);
+ p[p_len + copy_len] = '\0';
+ return p;
+ }
+@@ -329,7 +354,7 @@ __FORTIFY_INLINE void *memset(void *p, int c, __kernel_size_t size)
+ __write_overflow();
+ if (p_size < size)
+ fortify_panic(__func__);
+- return __builtin_memset(p, c, size);
++ return __underlying_memset(p, c, size);
+ }
+
+ __FORTIFY_INLINE void *memcpy(void *p, const void *q, __kernel_size_t size)
+@@ -344,7 +369,7 @@ __FORTIFY_INLINE void *memcpy(void *p, const void *q, __kernel_size_t size)
+ }
+ if (p_size < size || q_size < size)
+ fortify_panic(__func__);
+- return __builtin_memcpy(p, q, size);
++ return __underlying_memcpy(p, q, size);
+ }
+
+ __FORTIFY_INLINE void *memmove(void *p, const void *q, __kernel_size_t size)
+@@ -359,7 +384,7 @@ __FORTIFY_INLINE void *memmove(void *p, const void *q, __kernel_size_t size)
+ }
+ if (p_size < size || q_size < size)
+ fortify_panic(__func__);
+- return __builtin_memmove(p, q, size);
++ return __underlying_memmove(p, q, size);
+ }
+
+ extern void *__real_memscan(void *, int, __kernel_size_t) __RENAME(memscan);
+@@ -385,7 +410,7 @@ __FORTIFY_INLINE int memcmp(const void *p, const void *q, __kernel_size_t size)
+ }
+ if (p_size < size || q_size < size)
+ fortify_panic(__func__);
+- return __builtin_memcmp(p, q, size);
++ return __underlying_memcmp(p, q, size);
+ }
+
+ __FORTIFY_INLINE void *memchr(const void *p, int c, __kernel_size_t size)
+@@ -395,7 +420,7 @@ __FORTIFY_INLINE void *memchr(const void *p, int c, __kernel_size_t size)
+ __read_overflow();
+ if (p_size < size)
+ fortify_panic(__func__);
+- return __builtin_memchr(p, c, size);
++ return __underlying_memchr(p, c, size);
+ }
+
+ void *__real_memchr_inv(const void *s, int c, size_t n) __RENAME(memchr_inv);
+@@ -426,11 +451,22 @@ __FORTIFY_INLINE char *strcpy(char *p, const char *q)
+ size_t p_size = __builtin_object_size(p, 0);
+ size_t q_size = __builtin_object_size(q, 0);
+ if (p_size == (size_t)-1 && q_size == (size_t)-1)
+- return __builtin_strcpy(p, q);
++ return __underlying_strcpy(p, q);
+ memcpy(p, q, strlen(q) + 1);
+ return p;
+ }
+
++/* Don't use these outside the FORITFY_SOURCE implementation */
++#undef __underlying_memchr
++#undef __underlying_memcmp
++#undef __underlying_memcpy
++#undef __underlying_memmove
++#undef __underlying_memset
++#undef __underlying_strcat
++#undef __underlying_strcpy
++#undef __underlying_strlen
++#undef __underlying_strncat
++#undef __underlying_strncpy
+ #endif
+
+ /**
+--
+2.25.1
+
--- /dev/null
+From f81e74842f83ea8f0fbd92d7431bfb289d74d155 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 2 Apr 2020 08:43:54 -0700
+Subject: tools api fs: Make xxx__mountpoint() more scalable
+
+From: Stephane Eranian <eranian@google.com>
+
+[ Upstream commit c6fddb28bad26e5472cb7acf7b04cd5126f1a4ab ]
+
+The xxx_mountpoint() interface provided by fs.c finds mount points for
+common pseudo filesystems. The first time xxx_mountpoint() is invoked,
+it scans the mount table (/proc/mounts) looking for a match. If found,
+it is cached. The price to scan /proc/mounts is paid once if the mount
+is found.
+
+When the mount point is not found, subsequent calls to xxx_mountpoint()
+scan /proc/mounts over and over again. There is no caching.
+
+This causes a scaling issue in perf record with hugeltbfs__mountpoint().
+The function is called for each process found in
+synthesize__mmap_events(). If the machine has thousands of processes
+and if the /proc/mounts has many entries this could cause major overhead
+in perf record. We have observed multi-second slowdowns on some
+configurations.
+
+As an example on a laptop:
+
+Before:
+
+ $ sudo umount /dev/hugepages
+ $ strace -e trace=openat -o /tmp/tt perf record -a ls
+ $ fgrep mounts /tmp/tt
+ 285
+
+After:
+
+ $ sudo umount /dev/hugepages
+ $ strace -e trace=openat -o /tmp/tt perf record -a ls
+ $ fgrep mounts /tmp/tt
+ 1
+
+One could argue that the non-caching in case the moint point is not
+found is intentional. That way subsequent calls may discover a moint
+point if the sysadmin mounts the filesystem. But the same argument could
+be made against caching the mount point. It could be unmounted causing
+errors. It all depends on the intent of the interface. This patch
+assumes it is expected to scan /proc/mounts once. The patch documents
+the caching behavior in the fs.h header file.
+
+An alternative would be to just fix perf record. But it would solve the
+problem with hugetlbs__mountpoint() but there could be similar issues
+(possibly down the line) with other xxx_mountpoint() calls in perf or
+other tools.
+
+Signed-off-by: Stephane Eranian <eranian@google.com>
+Reviewed-by: Ian Rogers <irogers@google.com>
+Acked-by: Jiri Olsa <jolsa@redhat.com>
+Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
+Cc: Andrey Zhizhikin <andrey.z@gmail.com>
+Cc: Kan Liang <kan.liang@linux.intel.com>
+Cc: Kefeng Wang <wangkefeng.wang@huawei.com>
+Cc: Mark Rutland <mark.rutland@arm.com>
+Cc: Namhyung Kim <namhyung@kernel.org>
+Cc: Peter Zijlstra <peterz@infradead.org>
+Cc: Petr Mladek <pmladek@suse.com>
+Cc: Thomas Gleixner <tglx@linutronix.de>
+Link: http://lore.kernel.org/lkml/20200402154357.107873-3-irogers@google.com
+Signed-off-by: Ian Rogers <irogers@google.com>
+Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ tools/lib/api/fs/fs.c | 17 +++++++++++++++++
+ tools/lib/api/fs/fs.h | 12 ++++++++++++
+ 2 files changed, 29 insertions(+)
+
+diff --git a/tools/lib/api/fs/fs.c b/tools/lib/api/fs/fs.c
+index 45b50b89009a..c61841051a90 100644
+--- a/tools/lib/api/fs/fs.c
++++ b/tools/lib/api/fs/fs.c
+@@ -90,6 +90,7 @@ struct fs {
+ const char * const *mounts;
+ char path[PATH_MAX];
+ bool found;
++ bool checked;
+ long magic;
+ };
+
+@@ -111,31 +112,37 @@ static struct fs fs__entries[] = {
+ .name = "sysfs",
+ .mounts = sysfs__fs_known_mountpoints,
+ .magic = SYSFS_MAGIC,
++ .checked = false,
+ },
+ [FS__PROCFS] = {
+ .name = "proc",
+ .mounts = procfs__known_mountpoints,
+ .magic = PROC_SUPER_MAGIC,
++ .checked = false,
+ },
+ [FS__DEBUGFS] = {
+ .name = "debugfs",
+ .mounts = debugfs__known_mountpoints,
+ .magic = DEBUGFS_MAGIC,
++ .checked = false,
+ },
+ [FS__TRACEFS] = {
+ .name = "tracefs",
+ .mounts = tracefs__known_mountpoints,
+ .magic = TRACEFS_MAGIC,
++ .checked = false,
+ },
+ [FS__HUGETLBFS] = {
+ .name = "hugetlbfs",
+ .mounts = hugetlbfs__known_mountpoints,
+ .magic = HUGETLBFS_MAGIC,
++ .checked = false,
+ },
+ [FS__BPF_FS] = {
+ .name = "bpf",
+ .mounts = bpf_fs__known_mountpoints,
+ .magic = BPF_FS_MAGIC,
++ .checked = false,
+ },
+ };
+
+@@ -158,6 +165,7 @@ static bool fs__read_mounts(struct fs *fs)
+ }
+
+ fclose(fp);
++ fs->checked = true;
+ return fs->found = found;
+ }
+
+@@ -220,6 +228,7 @@ static bool fs__env_override(struct fs *fs)
+ return false;
+
+ fs->found = true;
++ fs->checked = true;
+ strncpy(fs->path, override_path, sizeof(fs->path) - 1);
+ fs->path[sizeof(fs->path) - 1] = '\0';
+ return true;
+@@ -246,6 +255,14 @@ static const char *fs__mountpoint(int idx)
+ if (fs->found)
+ return (const char *)fs->path;
+
++ /* the mount point was already checked for the mount point
++ * but and did not exist, so return NULL to avoid scanning again.
++ * This makes the found and not found paths cost equivalent
++ * in case of multiple calls.
++ */
++ if (fs->checked)
++ return NULL;
++
+ return fs__get_mountpoint(fs);
+ }
+
+diff --git a/tools/lib/api/fs/fs.h b/tools/lib/api/fs/fs.h
+index dda49deefb52..57a3dc160b08 100644
+--- a/tools/lib/api/fs/fs.h
++++ b/tools/lib/api/fs/fs.h
+@@ -18,6 +18,18 @@
+ const char *name##__mount(void); \
+ bool name##__configured(void); \
+
++/*
++ * The xxxx__mountpoint() entry points find the first match mount point for each
++ * filesystems listed below, where xxxx is the filesystem type.
++ *
++ * The interface is as follows:
++ *
++ * - If a mount point is found on first call, it is cached and used for all
++ * subsequent calls.
++ *
++ * - If a mount point is not found, NULL is returned on first call and all
++ * subsequent calls.
++ */
+ FS(sysfs)
+ FS(procfs)
+ FS(debugfs)
+--
+2.25.1
+
--- /dev/null
+From eac1adefef81e6a364417daace8f77b70123df89 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 8 May 2020 05:56:03 +0300
+Subject: wcn36xx: Fix error handling path in 'wcn36xx_probe()'
+
+From: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
+
+[ Upstream commit a86308fc534edeceaf64670c691e17485436a4f4 ]
+
+In case of error, 'qcom_wcnss_open_channel()' must be undone by a call to
+'rpmsg_destroy_ept()', as already done in the remove function.
+
+Fixes: 5052de8deff5 ("soc: qcom: smd: Transition client drivers from smd to rpmsg")
+Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
+Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
+Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
+Link: https://lore.kernel.org/r/20200507043619.200051-1-christophe.jaillet@wanadoo.fr
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/wireless/ath/wcn36xx/main.c | 6 ++++--
+ 1 file changed, 4 insertions(+), 2 deletions(-)
+
+diff --git a/drivers/net/wireless/ath/wcn36xx/main.c b/drivers/net/wireless/ath/wcn36xx/main.c
+index af37c19dbfd7..688152bcfc15 100644
+--- a/drivers/net/wireless/ath/wcn36xx/main.c
++++ b/drivers/net/wireless/ath/wcn36xx/main.c
+@@ -1280,7 +1280,7 @@ static int wcn36xx_probe(struct platform_device *pdev)
+ if (addr && ret != ETH_ALEN) {
+ wcn36xx_err("invalid local-mac-address\n");
+ ret = -EINVAL;
+- goto out_wq;
++ goto out_destroy_ept;
+ } else if (addr) {
+ wcn36xx_info("mac address: %pM\n", addr);
+ SET_IEEE80211_PERM_ADDR(wcn->hw, addr);
+@@ -1288,7 +1288,7 @@ static int wcn36xx_probe(struct platform_device *pdev)
+
+ ret = wcn36xx_platform_get_resources(wcn, pdev);
+ if (ret)
+- goto out_wq;
++ goto out_destroy_ept;
+
+ wcn36xx_init_ieee80211(wcn);
+ ret = ieee80211_register_hw(wcn->hw);
+@@ -1300,6 +1300,8 @@ static int wcn36xx_probe(struct platform_device *pdev)
+ out_unmap:
+ iounmap(wcn->ccu_base);
+ iounmap(wcn->dxe_base);
++out_destroy_ept:
++ rpmsg_destroy_ept(wcn->smd_channel);
+ out_wq:
+ ieee80211_free_hw(hw);
+ out_err:
+--
+2.25.1
+
--- /dev/null
+From 41508c9c4233922f9e8ca5efdfb0c05d6c319aa7 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 7 Feb 2020 16:49:26 -0500
+Subject: x86/boot: Correct relocation destination on old linkers
+
+From: Arvind Sankar <nivedita@alum.mit.edu>
+
+[ Upstream commit 5214028dd89e49ba27007c3ee475279e584261f0 ]
+
+For the 32-bit kernel, as described in
+
+ 6d92bc9d483a ("x86/build: Build compressed x86 kernels as PIE"),
+
+pre-2.26 binutils generates R_386_32 relocations in PIE mode. Since the
+startup code does not perform relocation, any reloc entry with R_386_32
+will remain as 0 in the executing code.
+
+Commit
+
+ 974f221c84b0 ("x86/boot: Move compressed kernel to the end of the
+ decompression buffer")
+
+added a new symbol _end but did not mark it hidden, which doesn't give
+the correct offset on older linkers. This causes the compressed kernel
+to be copied beyond the end of the decompression buffer, rather than
+flush against it. This region of memory may be reserved or already
+allocated for other purposes by the bootloader.
+
+Mark _end as hidden to fix. This changes the relocation from R_386_32 to
+R_386_RELATIVE even on the pre-2.26 binutils.
+
+For 64-bit, this is not strictly necessary, as the 64-bit kernel is only
+built as PIE if the linker supports -z noreloc-overflow, which implies
+binutils-2.27+, but for consistency, mark _end as hidden here too.
+
+The below illustrates the before/after impact of the patch using
+binutils-2.25 and gcc-4.6.4 (locally compiled from source) and QEMU.
+
+ Disassembly before patch:
+ 48: 8b 86 60 02 00 00 mov 0x260(%esi),%eax
+ 4e: 2d 00 00 00 00 sub $0x0,%eax
+ 4f: R_386_32 _end
+ Disassembly after patch:
+ 48: 8b 86 60 02 00 00 mov 0x260(%esi),%eax
+ 4e: 2d 00 f0 76 00 sub $0x76f000,%eax
+ 4f: R_386_RELATIVE *ABS*
+
+Dump from extract_kernel before patch:
+ early console in extract_kernel
+ input_data: 0x0207c098 <--- this is at output + init_size
+ input_len: 0x0074fef1
+ output: 0x01000000
+ output_len: 0x00fa63d0
+ kernel_total_size: 0x0107c000
+ needed_size: 0x0107c000
+
+Dump from extract_kernel after patch:
+ early console in extract_kernel
+ input_data: 0x0190d098 <--- this is at output + init_size - _end
+ input_len: 0x0074fef1
+ output: 0x01000000
+ output_len: 0x00fa63d0
+ kernel_total_size: 0x0107c000
+ needed_size: 0x0107c000
+
+Fixes: 974f221c84b0 ("x86/boot: Move compressed kernel to the end of the decompression buffer")
+Signed-off-by: Arvind Sankar <nivedita@alum.mit.edu>
+Signed-off-by: Borislav Petkov <bp@suse.de>
+Link: https://lkml.kernel.org/r/20200207214926.3564079-1-nivedita@alum.mit.edu
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ arch/x86/boot/compressed/head_32.S | 5 +++--
+ arch/x86/boot/compressed/head_64.S | 1 +
+ 2 files changed, 4 insertions(+), 2 deletions(-)
+
+diff --git a/arch/x86/boot/compressed/head_32.S b/arch/x86/boot/compressed/head_32.S
+index 01d628ea3402..c6c4b877f3d2 100644
+--- a/arch/x86/boot/compressed/head_32.S
++++ b/arch/x86/boot/compressed/head_32.S
+@@ -49,16 +49,17 @@
+ * Position Independent Executable (PIE) so that linker won't optimize
+ * R_386_GOT32X relocation to its fixed symbol address. Older
+ * linkers generate R_386_32 relocations against locally defined symbols,
+- * _bss, _ebss, _got and _egot, in PIE. It isn't wrong, just less
++ * _bss, _ebss, _got, _egot and _end, in PIE. It isn't wrong, just less
+ * optimal than R_386_RELATIVE. But the x86 kernel fails to properly handle
+ * R_386_32 relocations when relocating the kernel. To generate
+- * R_386_RELATIVE relocations, we mark _bss, _ebss, _got and _egot as
++ * R_386_RELATIVE relocations, we mark _bss, _ebss, _got, _egot and _end as
+ * hidden:
+ */
+ .hidden _bss
+ .hidden _ebss
+ .hidden _got
+ .hidden _egot
++ .hidden _end
+
+ __HEAD
+ ENTRY(startup_32)
+diff --git a/arch/x86/boot/compressed/head_64.S b/arch/x86/boot/compressed/head_64.S
+index a25127916e67..7ab1c6bcc66a 100644
+--- a/arch/x86/boot/compressed/head_64.S
++++ b/arch/x86/boot/compressed/head_64.S
+@@ -41,6 +41,7 @@
+ .hidden _ebss
+ .hidden _got
+ .hidden _egot
++ .hidden _end
+
+ __HEAD
+ .code32
+--
+2.25.1
+
--- /dev/null
+From f7632e156a212a18d1e0e8253647f4ead0e7c3e4 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 24 Apr 2020 14:37:40 +0300
+Subject: x86/kvm/hyper-v: Explicitly align hcall param for kvm_hyperv_exit
+
+From: Jon Doron <arilou@gmail.com>
+
+[ Upstream commit f7d31e65368aeef973fab788aa22c4f1d5a6af66 ]
+
+The problem the patch is trying to address is the fact that 'struct
+kvm_hyperv_exit' has different layout on when compiling in 32 and 64 bit
+modes.
+
+In 64-bit mode the default alignment boundary is 64 bits thus
+forcing extra gaps after 'type' and 'msr' but in 32-bit mode the
+boundary is at 32 bits thus no extra gaps.
+
+This is an issue as even when the kernel is 64 bit, the userspace using
+the interface can be both 32 and 64 bit but the same 32 bit userspace has
+to work with 32 bit kernel.
+
+The issue is fixed by forcing the 64 bit layout, this leads to ABI
+change for 32 bit builds and while we are obviously breaking '32 bit
+userspace with 32 bit kernel' case, we're fixing the '32 bit userspace
+with 64 bit kernel' one.
+
+As the interface has no (known) users and 32 bit KVM is rather baroque
+nowadays, this seems like a reasonable decision.
+
+Reviewed-by: Vitaly Kuznetsov <vkuznets@redhat.com>
+Signed-off-by: Jon Doron <arilou@gmail.com>
+Message-Id: <20200424113746.3473563-2-arilou@gmail.com>
+Reviewed-by: Roman Kagan <rvkagan@yandex-team.ru>
+Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ Documentation/virtual/kvm/api.txt | 2 ++
+ include/uapi/linux/kvm.h | 2 ++
+ 2 files changed, 4 insertions(+)
+
+diff --git a/Documentation/virtual/kvm/api.txt b/Documentation/virtual/kvm/api.txt
+index f67ed33d1054..81a8802cea88 100644
+--- a/Documentation/virtual/kvm/api.txt
++++ b/Documentation/virtual/kvm/api.txt
+@@ -3737,9 +3737,11 @@ EOI was received.
+ #define KVM_EXIT_HYPERV_SYNIC 1
+ #define KVM_EXIT_HYPERV_HCALL 2
+ __u32 type;
++ __u32 pad1;
+ union {
+ struct {
+ __u32 msr;
++ __u32 pad2;
+ __u64 control;
+ __u64 evt_page;
+ __u64 msg_page;
+diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
+index 27c62abb6c9e..efe8873943f6 100644
+--- a/include/uapi/linux/kvm.h
++++ b/include/uapi/linux/kvm.h
+@@ -189,9 +189,11 @@ struct kvm_hyperv_exit {
+ #define KVM_EXIT_HYPERV_SYNIC 1
+ #define KVM_EXIT_HYPERV_HCALL 2
+ __u32 type;
++ __u32 pad1;
+ union {
+ struct {
+ __u32 msr;
++ __u32 pad2;
+ __u64 control;
+ __u64 evt_page;
+ __u64 msg_page;
+--
+2.25.1
+
--- /dev/null
+From 786007f616af7b9be5c6ec7e3b17aab5037c9abe Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Sat, 29 Feb 2020 18:11:20 -0500
+Subject: x86/mm: Stop printing BRK addresses
+
+From: Arvind Sankar <nivedita@alum.mit.edu>
+
+[ Upstream commit 67d631b7c05eff955ccff4139327f0f92a5117e5 ]
+
+This currently leaks kernel physical addresses into userspace.
+
+Signed-off-by: Arvind Sankar <nivedita@alum.mit.edu>
+Signed-off-by: Borislav Petkov <bp@suse.de>
+Acked-by: Kees Cook <keescook@chromium.org>
+Acked-by: Dave Hansen <dave.hansen@intel.com>
+Link: https://lkml.kernel.org/r/20200229231120.1147527-1-nivedita@alum.mit.edu
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ arch/x86/mm/init.c | 2 --
+ 1 file changed, 2 deletions(-)
+
+diff --git a/arch/x86/mm/init.c b/arch/x86/mm/init.c
+index 32bb38f6fc18..8039a951db8f 100644
+--- a/arch/x86/mm/init.c
++++ b/arch/x86/mm/init.c
+@@ -112,8 +112,6 @@ __ref void *alloc_low_pages(unsigned int num)
+ } else {
+ pfn = pgt_buf_end;
+ pgt_buf_end += num;
+- printk(KERN_DEBUG "BRK [%#010lx, %#010lx] PGTABLE\n",
+- pfn << PAGE_SHIFT, (pgt_buf_end << PAGE_SHIFT) - 1);
+ }
+
+ for (i = 0; i < num; i++) {
+--
+2.25.1
+
projects / thirdparty / kernel / stable-queue.git / commitdiff
