From bf7def3315152c234b59d8f59d865602cb40640d Mon Sep 17 00:00:00 2001 From: Greg Kroah-Hartman Date: Mon, 6 Jun 2022 17:20:46 +0200 Subject: [PATCH] 4.14-stable patches added patches: asoc-rt5514-fix-event-generation-for-dsp-voice-wake-up-control.patch carl9170-tx-fix-an-incorrect-use-of-list-iterator.patch hugetlb-fix-huge_pmd_unshare-address-update.patch iommu-msm-fix-an-incorrect-null-check-on-list-iterator.patch irqchip-armada-370-xp-do-not-touch-performance-counter-overflow-on-a375-a38x-a39x.patch irqchip-irq-xtensa-mx-fix-initial-irq-affinity.patch mac80211-upgrade-passive-scan-to-active-scan-on-dfs-channels-after-beacon-rx.patch nodemask.h-fix-compilation-error-with-gcc12.patch rdma-hfi1-fix-potential-integer-multiplication-overflow-errors.patch rtl818x-prevent-using-not-initialized-queues.patch um-chan_user-fix-winch_tramp-return-value.patch um-fix-out-of-bounds-read-in-ldt-setup.patch --- ...ration-for-dsp-voice-wake-up-control.patch | 34 ++++++ ...ix-an-incorrect-use-of-list-iterator.patch | 44 ++++++++ ...-fix-huge_pmd_unshare-address-update.patch | 47 ++++++++ ...ncorrect-null-check-on-list-iterator.patch | 58 ++++++++++ ...e-counter-overflow-on-a375-a38x-a39x.patch | 48 ++++++++ ...q-xtensa-mx-fix-initial-irq-affinity.patch | 62 +++++++++++ ...scan-on-dfs-channels-after-beacon-rx.patch | 103 ++++++++++++++++++ ...k.h-fix-compilation-error-with-gcc12.patch | 92 ++++++++++++++++ ...teger-multiplication-overflow-errors.patch | 40 +++++++ ...prevent-using-not-initialized-queues.patch | 70 ++++++++++++ queue-4.14/series | 12 ++ ...an_user-fix-winch_tramp-return-value.patch | 64 +++++++++++ ...-fix-out-of-bounds-read-in-ldt-setup.patch | 71 ++++++++++++ 13 files changed, 745 insertions(+) create mode 100644 queue-4.14/asoc-rt5514-fix-event-generation-for-dsp-voice-wake-up-control.patch create mode 100644 queue-4.14/carl9170-tx-fix-an-incorrect-use-of-list-iterator.patch create mode 100644 queue-4.14/hugetlb-fix-huge_pmd_unshare-address-update.patch create mode 100644 queue-4.14/iommu-msm-fix-an-incorrect-null-check-on-list-iterator.patch create mode 100644 queue-4.14/irqchip-armada-370-xp-do-not-touch-performance-counter-overflow-on-a375-a38x-a39x.patch create mode 100644 queue-4.14/irqchip-irq-xtensa-mx-fix-initial-irq-affinity.patch create mode 100644 queue-4.14/mac80211-upgrade-passive-scan-to-active-scan-on-dfs-channels-after-beacon-rx.patch create mode 100644 queue-4.14/nodemask.h-fix-compilation-error-with-gcc12.patch create mode 100644 queue-4.14/rdma-hfi1-fix-potential-integer-multiplication-overflow-errors.patch create mode 100644 queue-4.14/rtl818x-prevent-using-not-initialized-queues.patch create mode 100644 queue-4.14/um-chan_user-fix-winch_tramp-return-value.patch create mode 100644 queue-4.14/um-fix-out-of-bounds-read-in-ldt-setup.patch diff --git a/queue-4.14/asoc-rt5514-fix-event-generation-for-dsp-voice-wake-up-control.patch b/queue-4.14/asoc-rt5514-fix-event-generation-for-dsp-voice-wake-up-control.patch new file mode 100644 index 00000000000..7e684b7d3ac --- /dev/null +++ b/queue-4.14/asoc-rt5514-fix-event-generation-for-dsp-voice-wake-up-control.patch @@ -0,0 +1,34 @@ +From 4213ff556740bb45e2d9ff0f50d056c4e7dd0921 Mon Sep 17 00:00:00 2001 +From: Mark Brown +Date: Thu, 28 Apr 2022 17:24:44 +0100 +Subject: ASoC: rt5514: Fix event generation for "DSP Voice Wake Up" control + +From: Mark Brown + +commit 4213ff556740bb45e2d9ff0f50d056c4e7dd0921 upstream. + +The driver has a custom put function for "DSP Voice Wake Up" which does +not generate event notifications on change, instead returning 0. Since we +already exit early in the case that there is no change this can be fixed +by unconditionally returning 1 at the end of the function. + +Signed-off-by: Mark Brown +Cc: stable@vger.kernel.org +Link: https://lore.kernel.org/r/20220428162444.3883147-1-broonie@kernel.org +Signed-off-by: Mark Brown +Signed-off-by: Greg Kroah-Hartman +--- + sound/soc/codecs/rt5514.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/sound/soc/codecs/rt5514.c ++++ b/sound/soc/codecs/rt5514.c +@@ -352,7 +352,7 @@ static int rt5514_dsp_voice_wake_up_put( + } + } + +- return 0; ++ return 1; + } + + static const struct snd_kcontrol_new rt5514_snd_controls[] = { diff --git a/queue-4.14/carl9170-tx-fix-an-incorrect-use-of-list-iterator.patch b/queue-4.14/carl9170-tx-fix-an-incorrect-use-of-list-iterator.patch new file mode 100644 index 00000000000..1518dcf7ba1 --- /dev/null +++ b/queue-4.14/carl9170-tx-fix-an-incorrect-use-of-list-iterator.patch @@ -0,0 +1,44 @@ +From 54a6f29522da3c914da30e50721dedf51046449a Mon Sep 17 00:00:00 2001 +From: Xiaomeng Tong +Date: Mon, 28 Mar 2022 20:28:20 +0800 +Subject: carl9170: tx: fix an incorrect use of list iterator + +From: Xiaomeng Tong + +commit 54a6f29522da3c914da30e50721dedf51046449a upstream. + +If the previous list_for_each_entry_continue_rcu() don't exit early +(no goto hit inside the loop), the iterator 'cvif' after the loop +will be a bogus pointer to an invalid structure object containing +the HEAD (&ar->vif_list). As a result, the use of 'cvif' after that +will lead to a invalid memory access (i.e., 'cvif->id': the invalid +pointer dereference when return back to/after the callsite in the +carl9170_update_beacon()). + +The original intention should have been to return the valid 'cvif' +when found in list, NULL otherwise. So just return NULL when no +entry found, to fix this bug. + +Cc: stable@vger.kernel.org +Fixes: 1f1d9654e183c ("carl9170: refactor carl9170_update_beacon") +Signed-off-by: Xiaomeng Tong +Acked-by: Christian Lamparter +Signed-off-by: Kalle Valo +Link: https://lore.kernel.org/r/20220328122820.1004-1-xiam0nd.tong@gmail.com +Signed-off-by: Greg Kroah-Hartman +--- + drivers/net/wireless/ath/carl9170/tx.c | 3 +++ + 1 file changed, 3 insertions(+) + +--- a/drivers/net/wireless/ath/carl9170/tx.c ++++ b/drivers/net/wireless/ath/carl9170/tx.c +@@ -1554,6 +1554,9 @@ static struct carl9170_vif_info *carl917 + goto out; + } + } while (ar->beacon_enabled && i--); ++ ++ /* no entry found in list */ ++ return NULL; + } + + out: diff --git a/queue-4.14/hugetlb-fix-huge_pmd_unshare-address-update.patch b/queue-4.14/hugetlb-fix-huge_pmd_unshare-address-update.patch new file mode 100644 index 00000000000..0fb36ade866 --- /dev/null +++ b/queue-4.14/hugetlb-fix-huge_pmd_unshare-address-update.patch @@ -0,0 +1,47 @@ +From 48381273f8734d28ef56a5bdf1966dd8530111bc Mon Sep 17 00:00:00 2001 +From: Mike Kravetz +Date: Tue, 24 May 2022 13:50:03 -0700 +Subject: hugetlb: fix huge_pmd_unshare address update + +From: Mike Kravetz + +commit 48381273f8734d28ef56a5bdf1966dd8530111bc upstream. + +The routine huge_pmd_unshare() is passed a pointer to an address +associated with an area which may be unshared. If unshare is successful +this address is updated to 'optimize' callers iterating over huge page +addresses. For the optimization to work correctly, address should be +updated to the last huge page in the unmapped/unshared area. However, in +the common case where the passed address is PUD_SIZE aligned, the address +is incorrectly updated to the address of the preceding huge page. That +wastes CPU cycles as the unmapped/unshared range is scanned twice. + +Link: https://lkml.kernel.org/r/20220524205003.126184-1-mike.kravetz@oracle.com +Fixes: 39dde65c9940 ("shared page table for hugetlb page") +Signed-off-by: Mike Kravetz +Acked-by: Muchun Song +Cc: +Signed-off-by: Andrew Morton +Signed-off-by: Greg Kroah-Hartman +--- + mm/hugetlb.c | 9 ++++++++- + 1 file changed, 8 insertions(+), 1 deletion(-) + +--- a/mm/hugetlb.c ++++ b/mm/hugetlb.c +@@ -4798,7 +4798,14 @@ int huge_pmd_unshare(struct mm_struct *m + pud_clear(pud); + put_page(virt_to_page(ptep)); + mm_dec_nr_pmds(mm); +- *addr = ALIGN(*addr, HPAGE_SIZE * PTRS_PER_PTE) - HPAGE_SIZE; ++ /* ++ * This update of passed address optimizes loops sequentially ++ * processing addresses in increments of huge page size (PMD_SIZE ++ * in this case). By clearing the pud, a PUD_SIZE area is unmapped. ++ * Update address to the 'last page' in the cleared area so that ++ * calling loop can move to first page past this area. ++ */ ++ *addr |= PUD_SIZE - PMD_SIZE; + return 1; + } + #define want_pmd_share() (1) diff --git a/queue-4.14/iommu-msm-fix-an-incorrect-null-check-on-list-iterator.patch b/queue-4.14/iommu-msm-fix-an-incorrect-null-check-on-list-iterator.patch new file mode 100644 index 00000000000..aaecf4472e8 --- /dev/null +++ b/queue-4.14/iommu-msm-fix-an-incorrect-null-check-on-list-iterator.patch @@ -0,0 +1,58 @@ +From 8b9ad480bd1dd25f4ff4854af5685fa334a2f57a Mon Sep 17 00:00:00 2001 +From: Xiaomeng Tong +Date: Sun, 1 May 2022 21:28:23 +0800 +Subject: iommu/msm: Fix an incorrect NULL check on list iterator + +From: Xiaomeng Tong + +commit 8b9ad480bd1dd25f4ff4854af5685fa334a2f57a upstream. + +The bug is here: + if (!iommu || iommu->dev->of_node != spec->np) { + +The list iterator value 'iommu' will *always* be set and non-NULL by +list_for_each_entry(), so it is incorrect to assume that the iterator +value will be NULL if the list is empty or no element is found (in fact, +it will point to a invalid structure object containing HEAD). + +To fix the bug, use a new value 'iter' as the list iterator, while use +the old value 'iommu' as a dedicated variable to point to the found one, +and remove the unneeded check for 'iommu->dev->of_node != spec->np' +outside the loop. + +Cc: stable@vger.kernel.org +Fixes: f78ebca8ff3d6 ("iommu/msm: Add support for generic master bindings") +Signed-off-by: Xiaomeng Tong +Link: https://lore.kernel.org/r/20220501132823.12714-1-xiam0nd.tong@gmail.com +Signed-off-by: Joerg Roedel +Signed-off-by: Greg Kroah-Hartman +--- + drivers/iommu/msm_iommu.c | 11 +++++++---- + 1 file changed, 7 insertions(+), 4 deletions(-) + +--- a/drivers/iommu/msm_iommu.c ++++ b/drivers/iommu/msm_iommu.c +@@ -638,16 +638,19 @@ static void insert_iommu_master(struct d + static int qcom_iommu_of_xlate(struct device *dev, + struct of_phandle_args *spec) + { +- struct msm_iommu_dev *iommu; ++ struct msm_iommu_dev *iommu = NULL, *iter; + unsigned long flags; + int ret = 0; + + spin_lock_irqsave(&msm_iommu_lock, flags); +- list_for_each_entry(iommu, &qcom_iommu_devices, dev_node) +- if (iommu->dev->of_node == spec->np) ++ list_for_each_entry(iter, &qcom_iommu_devices, dev_node) { ++ if (iter->dev->of_node == spec->np) { ++ iommu = iter; + break; ++ } ++ } + +- if (!iommu || iommu->dev->of_node != spec->np) { ++ if (!iommu) { + ret = -ENODEV; + goto fail; + } diff --git a/queue-4.14/irqchip-armada-370-xp-do-not-touch-performance-counter-overflow-on-a375-a38x-a39x.patch b/queue-4.14/irqchip-armada-370-xp-do-not-touch-performance-counter-overflow-on-a375-a38x-a39x.patch new file mode 100644 index 00000000000..ad619cb13e8 --- /dev/null +++ b/queue-4.14/irqchip-armada-370-xp-do-not-touch-performance-counter-overflow-on-a375-a38x-a39x.patch @@ -0,0 +1,48 @@ +From a3d66a76348daf559873f19afc912a2a7c2ccdaf Mon Sep 17 00:00:00 2001 +From: =?UTF-8?q?Pali=20Roh=C3=A1r?= +Date: Mon, 25 Apr 2022 13:37:05 +0200 +Subject: irqchip/armada-370-xp: Do not touch Performance Counter Overflow on A375, A38x, A39x +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Pali Rohár + +commit a3d66a76348daf559873f19afc912a2a7c2ccdaf upstream. + +Register ARMADA_370_XP_INT_FABRIC_MASK_OFFS is Armada 370 and XP specific +and on new Armada platforms it has different meaning. It does not configure +Performance Counter Overflow interrupt masking. So do not touch this +register on non-A370/XP platforms (A375, A38x and A39x). + +Signed-off-by: Pali Rohár +Cc: stable@vger.kernel.org +Fixes: 28da06dfd9e4 ("irqchip: armada-370-xp: Enable the PMU interrupts") +Reviewed-by: Andrew Lunn +Signed-off-by: Marc Zyngier +Link: https://lore.kernel.org/r/20220425113706.29310-1-pali@kernel.org +Signed-off-by: Greg Kroah-Hartman +--- + drivers/irqchip/irq-armada-370-xp.c | 11 ++++++++++- + 1 file changed, 10 insertions(+), 1 deletion(-) + +--- a/drivers/irqchip/irq-armada-370-xp.c ++++ b/drivers/irqchip/irq-armada-370-xp.c +@@ -392,7 +392,16 @@ static void armada_xp_mpic_smp_cpu_init( + + static void armada_xp_mpic_perf_init(void) + { +- unsigned long cpuid = cpu_logical_map(smp_processor_id()); ++ unsigned long cpuid; ++ ++ /* ++ * This Performance Counter Overflow interrupt is specific for ++ * Armada 370 and XP. It is not available on Armada 375, 38x and 39x. ++ */ ++ if (!of_machine_is_compatible("marvell,armada-370-xp")) ++ return; ++ ++ cpuid = cpu_logical_map(smp_processor_id()); + + /* Enable Performance Counter Overflow interrupts */ + writel(ARMADA_370_XP_INT_CAUSE_PERF(cpuid), diff --git a/queue-4.14/irqchip-irq-xtensa-mx-fix-initial-irq-affinity.patch b/queue-4.14/irqchip-irq-xtensa-mx-fix-initial-irq-affinity.patch new file mode 100644 index 00000000000..ade00db3afc --- /dev/null +++ b/queue-4.14/irqchip-irq-xtensa-mx-fix-initial-irq-affinity.patch @@ -0,0 +1,62 @@ +From a255ee29252066d621df5d6b420bf534c6ba5bc0 Mon Sep 17 00:00:00 2001 +From: Max Filippov +Date: Tue, 26 Apr 2022 09:01:18 -0700 +Subject: irqchip: irq-xtensa-mx: fix initial IRQ affinity + +From: Max Filippov + +commit a255ee29252066d621df5d6b420bf534c6ba5bc0 upstream. + +When irq-xtensa-mx chip is used in non-SMP configuration its +irq_set_affinity callback is not called leaving IRQ affinity set empty. +As a result IRQ delivery does not work in that configuration. +Initialize IRQ affinity of the xtensa MX interrupt distributor to CPU 0 +for all external IRQ lines. + +Cc: stable@vger.kernel.org +Signed-off-by: Max Filippov +Signed-off-by: Greg Kroah-Hartman +--- + drivers/irqchip/irq-xtensa-mx.c | 18 ++++++++++++++---- + 1 file changed, 14 insertions(+), 4 deletions(-) + +--- a/drivers/irqchip/irq-xtensa-mx.c ++++ b/drivers/irqchip/irq-xtensa-mx.c +@@ -143,14 +143,25 @@ static struct irq_chip xtensa_mx_irq_chi + .irq_set_affinity = xtensa_mx_irq_set_affinity, + }; + ++static void __init xtensa_mx_init_common(struct irq_domain *root_domain) ++{ ++ unsigned int i; ++ ++ irq_set_default_host(root_domain); ++ secondary_init_irq(); ++ ++ /* Initialize default IRQ routing to CPU 0 */ ++ for (i = 0; i < XCHAL_NUM_EXTINTERRUPTS; ++i) ++ set_er(1, MIROUT(i)); ++} ++ + int __init xtensa_mx_init_legacy(struct device_node *interrupt_parent) + { + struct irq_domain *root_domain = + irq_domain_add_legacy(NULL, NR_IRQS - 1, 1, 0, + &xtensa_mx_irq_domain_ops, + &xtensa_mx_irq_chip); +- irq_set_default_host(root_domain); +- secondary_init_irq(); ++ xtensa_mx_init_common(root_domain); + return 0; + } + +@@ -160,8 +171,7 @@ static int __init xtensa_mx_init(struct + struct irq_domain *root_domain = + irq_domain_add_linear(np, NR_IRQS, &xtensa_mx_irq_domain_ops, + &xtensa_mx_irq_chip); +- irq_set_default_host(root_domain); +- secondary_init_irq(); ++ xtensa_mx_init_common(root_domain); + return 0; + } + IRQCHIP_DECLARE(xtensa_mx_irq_chip, "cdns,xtensa-mx", xtensa_mx_init); diff --git a/queue-4.14/mac80211-upgrade-passive-scan-to-active-scan-on-dfs-channels-after-beacon-rx.patch b/queue-4.14/mac80211-upgrade-passive-scan-to-active-scan-on-dfs-channels-after-beacon-rx.patch new file mode 100644 index 00000000000..5145b2b8e98 --- /dev/null +++ b/queue-4.14/mac80211-upgrade-passive-scan-to-active-scan-on-dfs-channels-after-beacon-rx.patch @@ -0,0 +1,103 @@ +From b041b7b9de6e1d4362de855ab90f9d03ef323edd Mon Sep 17 00:00:00 2001 +From: Felix Fietkau +Date: Wed, 20 Apr 2022 12:49:07 +0200 +Subject: mac80211: upgrade passive scan to active scan on DFS channels after beacon rx + +From: Felix Fietkau + +commit b041b7b9de6e1d4362de855ab90f9d03ef323edd upstream. + +In client mode, we can't connect to hidden SSID APs or SSIDs not advertised +in beacons on DFS channels, since we're forced to passive scan. Fix this by +sending out a probe request immediately after the first beacon, if active +scan was requested by the user. + +Cc: stable@vger.kernel.org +Reported-by: Catrinel Catrinescu +Signed-off-by: Felix Fietkau +Link: https://lore.kernel.org/r/20220420104907.36275-1-nbd@nbd.name +Signed-off-by: Johannes Berg +Signed-off-by: Greg Kroah-Hartman +--- + net/mac80211/ieee80211_i.h | 5 +++++ + net/mac80211/scan.c | 20 ++++++++++++++++++++ + 2 files changed, 25 insertions(+) + +--- a/net/mac80211/ieee80211_i.h ++++ b/net/mac80211/ieee80211_i.h +@@ -1067,6 +1067,9 @@ struct tpt_led_trigger { + * a scan complete for an aborted scan. + * @SCAN_HW_CANCELLED: Set for our scan work function when the scan is being + * cancelled. ++ * @SCAN_BEACON_WAIT: Set whenever we're passive scanning because of radar/no-IR ++ * and could send a probe request after receiving a beacon. ++ * @SCAN_BEACON_DONE: Beacon received, we can now send a probe request + */ + enum { + SCAN_SW_SCANNING, +@@ -1075,6 +1078,8 @@ enum { + SCAN_COMPLETED, + SCAN_ABORTED, + SCAN_HW_CANCELLED, ++ SCAN_BEACON_WAIT, ++ SCAN_BEACON_DONE, + }; + + /** +--- a/net/mac80211/scan.c ++++ b/net/mac80211/scan.c +@@ -205,6 +205,16 @@ void ieee80211_scan_rx(struct ieee80211_ + if (likely(!sdata1 && !sdata2)) + return; + ++ if (test_and_clear_bit(SCAN_BEACON_WAIT, &local->scanning)) { ++ /* ++ * we were passive scanning because of radar/no-IR, but ++ * the beacon/proberesp rx gives us an opportunity to upgrade ++ * to active scan ++ */ ++ set_bit(SCAN_BEACON_DONE, &local->scanning); ++ ieee80211_queue_delayed_work(&local->hw, &local->scan_work, 0); ++ } ++ + if (ieee80211_is_probe_resp(mgmt->frame_control)) { + struct cfg80211_scan_request *scan_req; + struct cfg80211_sched_scan_request *sched_scan_req; +@@ -646,6 +656,8 @@ static int __ieee80211_start_scan(struct + IEEE80211_CHAN_RADAR)) || + !req->n_ssids) { + next_delay = IEEE80211_PASSIVE_CHANNEL_TIME; ++ if (req->n_ssids) ++ set_bit(SCAN_BEACON_WAIT, &local->scanning); + } else { + ieee80211_scan_state_send_probe(local, &next_delay); + next_delay = IEEE80211_CHANNEL_TIME; +@@ -826,6 +838,8 @@ static void ieee80211_scan_state_set_cha + !scan_req->n_ssids) { + *next_delay = IEEE80211_PASSIVE_CHANNEL_TIME; + local->next_scan_state = SCAN_DECISION; ++ if (scan_req->n_ssids) ++ set_bit(SCAN_BEACON_WAIT, &local->scanning); + return; + } + +@@ -918,6 +932,8 @@ void ieee80211_scan_work(struct work_str + goto out; + } + ++ clear_bit(SCAN_BEACON_WAIT, &local->scanning); ++ + /* + * as long as no delay is required advance immediately + * without scheduling a new work +@@ -928,6 +944,10 @@ void ieee80211_scan_work(struct work_str + goto out_complete; + } + ++ if (test_and_clear_bit(SCAN_BEACON_DONE, &local->scanning) && ++ local->next_scan_state == SCAN_DECISION) ++ local->next_scan_state = SCAN_SEND_PROBE; ++ + switch (local->next_scan_state) { + case SCAN_DECISION: + /* if no more bands/channels left, complete scan */ diff --git a/queue-4.14/nodemask.h-fix-compilation-error-with-gcc12.patch b/queue-4.14/nodemask.h-fix-compilation-error-with-gcc12.patch new file mode 100644 index 00000000000..b98ba67b5f6 --- /dev/null +++ b/queue-4.14/nodemask.h-fix-compilation-error-with-gcc12.patch @@ -0,0 +1,92 @@ +From 37462a920392cb86541650a6f4121155f11f1199 Mon Sep 17 00:00:00 2001 +From: Christophe de Dinechin +Date: Thu, 14 Apr 2022 17:08:54 +0200 +Subject: nodemask.h: fix compilation error with GCC12 + +From: Christophe de Dinechin + +commit 37462a920392cb86541650a6f4121155f11f1199 upstream. + +With gcc version 12.0.1 20220401 (Red Hat 12.0.1-0), building with +defconfig results in the following compilation error: + +| CC mm/swapfile.o +| mm/swapfile.c: In function `setup_swap_info': +| mm/swapfile.c:2291:47: error: array subscript -1 is below array bounds +| of `struct plist_node[]' [-Werror=array-bounds] +| 2291 | p->avail_lists[i].prio = 1; +| | ~~~~~~~~~~~~~~^~~ +| In file included from mm/swapfile.c:16: +| ./include/linux/swap.h:292:27: note: while referencing `avail_lists' +| 292 | struct plist_node avail_lists[]; /* +| | ^~~~~~~~~~~ + +This is due to the compiler detecting that the mask in +node_states[__state] could theoretically be zero, which would lead to +first_node() returning -1 through find_first_bit. + +I believe that the warning/error is legitimate. I first tried adding a +test to check that the node mask is not emtpy, since a similar test exists +in the case where MAX_NUMNODES == 1. + +However, adding the if statement causes other warnings to appear in +for_each_cpu_node_but, because it introduces a dangling else ambiguity. +And unfortunately, GCC is not smart enough to detect that the added test +makes the case where (node) == -1 impossible, so it still complains with +the same message. + +This is why I settled on replacing that with a harmless, but relatively +useless (node) >= 0 test. Based on the warning for the dangling else, I +also decided to fix the case where MAX_NUMNODES == 1 by moving the +condition inside the for loop. It will still only be tested once. This +ensures that the meaning of an else following for_each_node_mask or +derivatives would not silently have a different meaning depending on the +configuration. + +Link: https://lkml.kernel.org/r/20220414150855.2407137-3-dinechin@redhat.com +Signed-off-by: Christophe de Dinechin +Signed-off-by: Christophe de Dinechin +Reviewed-by: Andrew Morton +Cc: Ben Segall +Cc: "Michael S. Tsirkin" +Cc: Steven Rostedt +Cc: Ingo Molnar +Cc: Mel Gorman +Cc: Dietmar Eggemann +Cc: Vincent Guittot +Cc: Paolo Bonzini +Cc: Daniel Bristot de Oliveira +Cc: Jason Wang +Cc: Zhen Lei +Cc: Juri Lelli +Cc: Peter Zijlstra +Cc: +Signed-off-by: Andrew Morton +Signed-off-by: Greg Kroah-Hartman +--- + include/linux/nodemask.h | 13 ++++++------- + 1 file changed, 6 insertions(+), 7 deletions(-) + +--- a/include/linux/nodemask.h ++++ b/include/linux/nodemask.h +@@ -366,14 +366,13 @@ static inline void __nodes_fold(nodemask + } + + #if MAX_NUMNODES > 1 +-#define for_each_node_mask(node, mask) \ +- for ((node) = first_node(mask); \ +- (node) < MAX_NUMNODES; \ +- (node) = next_node((node), (mask))) ++#define for_each_node_mask(node, mask) \ ++ for ((node) = first_node(mask); \ ++ (node >= 0) && (node) < MAX_NUMNODES; \ ++ (node) = next_node((node), (mask))) + #else /* MAX_NUMNODES == 1 */ +-#define for_each_node_mask(node, mask) \ +- if (!nodes_empty(mask)) \ +- for ((node) = 0; (node) < 1; (node)++) ++#define for_each_node_mask(node, mask) \ ++ for ((node) = 0; (node) < 1 && !nodes_empty(mask); (node)++) + #endif /* MAX_NUMNODES */ + + /* diff --git a/queue-4.14/rdma-hfi1-fix-potential-integer-multiplication-overflow-errors.patch b/queue-4.14/rdma-hfi1-fix-potential-integer-multiplication-overflow-errors.patch new file mode 100644 index 00000000000..4df427d11b7 --- /dev/null +++ b/queue-4.14/rdma-hfi1-fix-potential-integer-multiplication-overflow-errors.patch @@ -0,0 +1,40 @@ +From f93e91a0372c922c20d5bee260b0f43b4b8a1bee Mon Sep 17 00:00:00 2001 +From: Dennis Dalessandro +Date: Fri, 20 May 2022 14:37:12 -0400 +Subject: RDMA/hfi1: Fix potential integer multiplication overflow errors + +From: Dennis Dalessandro + +commit f93e91a0372c922c20d5bee260b0f43b4b8a1bee upstream. + +When multiplying of different types, an overflow is possible even when +storing the result in a larger type. This is because the conversion is +done after the multiplication. So arithmetic overflow and thus in +incorrect value is possible. + +Correct an instance of this in the inter packet delay calculation. Fix by +ensuring one of the operands is u64 which will promote the other to u64 as +well ensuring no overflow. + +Cc: stable@vger.kernel.org +Fixes: 7724105686e7 ("IB/hfi1: add driver files") +Link: https://lore.kernel.org/r/20220520183712.48973.29855.stgit@awfm-01.cornelisnetworks.com +Reviewed-by: Mike Marciniszyn +Signed-off-by: Dennis Dalessandro +Signed-off-by: Jason Gunthorpe +Signed-off-by: Greg Kroah-Hartman +--- + drivers/infiniband/hw/hfi1/init.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/infiniband/hw/hfi1/init.c ++++ b/drivers/infiniband/hw/hfi1/init.c +@@ -515,7 +515,7 @@ void set_link_ipg(struct hfi1_pportdata + u16 shift, mult; + u64 src; + u32 current_egress_rate; /* Mbits /sec */ +- u32 max_pkt_time; ++ u64 max_pkt_time; + /* + * max_pkt_time is the maximum packet egress time in units + * of the fabric clock period 1/(805 MHz). diff --git a/queue-4.14/rtl818x-prevent-using-not-initialized-queues.patch b/queue-4.14/rtl818x-prevent-using-not-initialized-queues.patch new file mode 100644 index 00000000000..b9462ac407a --- /dev/null +++ b/queue-4.14/rtl818x-prevent-using-not-initialized-queues.patch @@ -0,0 +1,70 @@ +From 746285cf81dc19502ab238249d75f5990bd2d231 Mon Sep 17 00:00:00 2001 +From: Alexander Wetzel +Date: Fri, 22 Apr 2022 16:52:28 +0200 +Subject: rtl818x: Prevent using not initialized queues + +From: Alexander Wetzel + +commit 746285cf81dc19502ab238249d75f5990bd2d231 upstream. + +Using not existing queues can panic the kernel with rtl8180/rtl8185 cards. +Ignore the skb priority for those cards, they only have one tx queue. Pierre +Asselin (pa@panix.com) reported the kernel crash in the Gentoo forum: + +https://forums.gentoo.org/viewtopic-t-1147832-postdays-0-postorder-asc-start-25.html + +He also confirmed that this patch fixes the issue. In summary this happened: + +After updating wpa_supplicant from 2.9 to 2.10 the kernel crashed with a +"divide error: 0000" when connecting to an AP. Control port tx now tries to +use IEEE80211_AC_VO for the priority, which wpa_supplicants starts to use in +2.10. + +Since only the rtl8187se part of the driver supports QoS, the priority +of the skb is set to IEEE80211_AC_BE (2) by mac80211 for rtl8180/rtl8185 +cards. + +rtl8180 is then unconditionally reading out the priority and finally crashes on +drivers/net/wireless/realtek/rtl818x/rtl8180/dev.c line 544 without this +patch: + idx = (ring->idx + skb_queue_len(&ring->queue)) % ring->entries + +"ring->entries" is zero for rtl8180/rtl8185 cards, tx_ring[2] never got +initialized. + +Cc: stable@vger.kernel.org +Reported-by: pa@panix.com +Tested-by: pa@panix.com +Signed-off-by: Alexander Wetzel +Signed-off-by: Kalle Valo +Link: https://lore.kernel.org/r/20220422145228.7567-1-alexander@wetzel-home.de +Signed-off-by: Greg Kroah-Hartman +--- + drivers/net/wireless/realtek/rtl818x/rtl8180/dev.c | 8 ++++++-- + 1 file changed, 6 insertions(+), 2 deletions(-) + +--- a/drivers/net/wireless/realtek/rtl818x/rtl8180/dev.c ++++ b/drivers/net/wireless/realtek/rtl818x/rtl8180/dev.c +@@ -460,8 +460,10 @@ static void rtl8180_tx(struct ieee80211_ + struct rtl8180_priv *priv = dev->priv; + struct rtl8180_tx_ring *ring; + struct rtl8180_tx_desc *entry; ++ unsigned int prio = 0; + unsigned long flags; +- unsigned int idx, prio, hw_prio; ++ unsigned int idx, hw_prio; ++ + dma_addr_t mapping; + u32 tx_flags; + u8 rc_flags; +@@ -470,7 +472,9 @@ static void rtl8180_tx(struct ieee80211_ + /* do arithmetic and then convert to le16 */ + u16 frame_duration = 0; + +- prio = skb_get_queue_mapping(skb); ++ /* rtl8180/rtl8185 only has one useable tx queue */ ++ if (dev->queues > IEEE80211_AC_BK) ++ prio = skb_get_queue_mapping(skb); + ring = &priv->tx_ring[prio]; + + mapping = pci_map_single(priv->pdev, skb->data, diff --git a/queue-4.14/series b/queue-4.14/series index f912db11be5..643fcf020b0 100644 --- a/queue-4.14/series +++ b/queue-4.14/series @@ -117,3 +117,15 @@ drm-nouveau-clk-fix-an-incorrect-null-check-on-list-iterator.patch drm-bridge-analogix_dp-grab-runtime-pm-reference-for-dp-aux.patch md-fix-an-incorrect-null-check-in-does_sb_need_changing.patch md-fix-an-incorrect-null-check-in-md_reload_sb.patch +rdma-hfi1-fix-potential-integer-multiplication-overflow-errors.patch +irqchip-armada-370-xp-do-not-touch-performance-counter-overflow-on-a375-a38x-a39x.patch +irqchip-irq-xtensa-mx-fix-initial-irq-affinity.patch +mac80211-upgrade-passive-scan-to-active-scan-on-dfs-channels-after-beacon-rx.patch +um-chan_user-fix-winch_tramp-return-value.patch +um-fix-out-of-bounds-read-in-ldt-setup.patch +iommu-msm-fix-an-incorrect-null-check-on-list-iterator.patch +nodemask.h-fix-compilation-error-with-gcc12.patch +hugetlb-fix-huge_pmd_unshare-address-update.patch +rtl818x-prevent-using-not-initialized-queues.patch +asoc-rt5514-fix-event-generation-for-dsp-voice-wake-up-control.patch +carl9170-tx-fix-an-incorrect-use-of-list-iterator.patch diff --git a/queue-4.14/um-chan_user-fix-winch_tramp-return-value.patch b/queue-4.14/um-chan_user-fix-winch_tramp-return-value.patch new file mode 100644 index 00000000000..8cc9b1af57c --- /dev/null +++ b/queue-4.14/um-chan_user-fix-winch_tramp-return-value.patch @@ -0,0 +1,64 @@ +From 57ae0b67b747031bc41fb44643aa5344ab58607e Mon Sep 17 00:00:00 2001 +From: Johannes Berg +Date: Fri, 20 May 2022 19:45:36 +0200 +Subject: um: chan_user: Fix winch_tramp() return value + +From: Johannes Berg + +commit 57ae0b67b747031bc41fb44643aa5344ab58607e upstream. + +The previous fix here was only partially correct, it did +result in returning a proper error value in case of error, +but it also clobbered the pid that we need to return from +this function (not just zero for success). + +As a result, it returned 0 here, but later this is treated +as a pid and used to kill the process, but since it's now +0 we kill(0, SIGKILL), which makes UML kill itself rather +than just the helper thread. + +Fix that and make it more obvious by using a separate +variable for the pid. + +Fixes: ccf1236ecac4 ("um: fix error return code in winch_tramp()") +Reported-and-tested-by: Nathan Chancellor +Signed-off-by: Johannes Berg +Cc: stable@vger.kernel.org +Signed-off-by: Richard Weinberger +Signed-off-by: Greg Kroah-Hartman +--- + arch/um/drivers/chan_user.c | 9 +++++---- + 1 file changed, 5 insertions(+), 4 deletions(-) + +--- a/arch/um/drivers/chan_user.c ++++ b/arch/um/drivers/chan_user.c +@@ -220,7 +220,7 @@ static int winch_tramp(int fd, struct tt + unsigned long *stack_out) + { + struct winch_data data; +- int fds[2], n, err; ++ int fds[2], n, err, pid; + char c; + + err = os_pipe(fds, 1, 1); +@@ -238,8 +238,9 @@ static int winch_tramp(int fd, struct tt + * problem with /dev/net/tun, which if held open by this + * thread, prevents the TUN/TAP device from being reused. + */ +- err = run_helper_thread(winch_thread, &data, CLONE_FILES, stack_out); +- if (err < 0) { ++ pid = run_helper_thread(winch_thread, &data, CLONE_FILES, stack_out); ++ if (pid < 0) { ++ err = pid; + printk(UM_KERN_ERR "fork of winch_thread failed - errno = %d\n", + -err); + goto out_close; +@@ -263,7 +264,7 @@ static int winch_tramp(int fd, struct tt + goto out_close; + } + +- return err; ++ return pid; + + out_close: + close(fds[1]); diff --git a/queue-4.14/um-fix-out-of-bounds-read-in-ldt-setup.patch b/queue-4.14/um-fix-out-of-bounds-read-in-ldt-setup.patch new file mode 100644 index 00000000000..11236e74beb --- /dev/null +++ b/queue-4.14/um-fix-out-of-bounds-read-in-ldt-setup.patch @@ -0,0 +1,71 @@ +From 2a4a62a14be1947fa945c5c11ebf67326381a568 Mon Sep 17 00:00:00 2001 +From: Vincent Whitchurch +Date: Mon, 23 May 2022 16:04:03 +0200 +Subject: um: Fix out-of-bounds read in LDT setup + +From: Vincent Whitchurch + +commit 2a4a62a14be1947fa945c5c11ebf67326381a568 upstream. + +syscall_stub_data() expects the data_count parameter to be the number of +longs, not bytes. + + ================================================================== + BUG: KASAN: stack-out-of-bounds in syscall_stub_data+0x70/0xe0 + Read of size 128 at addr 000000006411f6f0 by task swapper/1 + + CPU: 0 PID: 1 Comm: swapper Not tainted 5.18.0+ #18 + Call Trace: + show_stack.cold+0x166/0x2a7 + __dump_stack+0x3a/0x43 + dump_stack_lvl+0x1f/0x27 + print_report.cold+0xdb/0xf81 + kasan_report+0x119/0x1f0 + kasan_check_range+0x3a3/0x440 + memcpy+0x52/0x140 + syscall_stub_data+0x70/0xe0 + write_ldt_entry+0xac/0x190 + init_new_ldt+0x515/0x960 + init_new_context+0x2c4/0x4d0 + mm_init.constprop.0+0x5ed/0x760 + mm_alloc+0x118/0x170 + 0x60033f48 + do_one_initcall+0x1d7/0x860 + 0x60003e7b + kernel_init+0x6e/0x3d4 + new_thread_handler+0x1e7/0x2c0 + + The buggy address belongs to stack of task swapper/1 + and is located at offset 64 in frame: + init_new_ldt+0x0/0x960 + + This frame has 2 objects: + [32, 40) 'addr' + [64, 80) 'desc' + ================================================================== + +Fixes: 858259cf7d1c443c83 ("uml: maintain own LDT entries") +Signed-off-by: Vincent Whitchurch +Cc: stable@vger.kernel.org +Signed-off-by: Richard Weinberger +Signed-off-by: Greg Kroah-Hartman +--- + arch/x86/um/ldt.c | 6 ++++-- + 1 file changed, 4 insertions(+), 2 deletions(-) + +--- a/arch/x86/um/ldt.c ++++ b/arch/x86/um/ldt.c +@@ -23,9 +23,11 @@ static long write_ldt_entry(struct mm_id + { + long res; + void *stub_addr; ++ ++ BUILD_BUG_ON(sizeof(*desc) % sizeof(long)); ++ + res = syscall_stub_data(mm_idp, (unsigned long *)desc, +- (sizeof(*desc) + sizeof(long) - 1) & +- ~(sizeof(long) - 1), ++ sizeof(*desc) / sizeof(long), + addr, &stub_addr); + if (!res) { + unsigned long args[] = { func, -- 2.47.3