From: Greg Kroah-Hartman Date: Mon, 9 May 2022 08:42:33 +0000 (+0200) Subject: 5.15-stable patches X-Git-Tag: v4.9.313~92 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=8f93250b0a12dda69f234f37f542705c21d0e3a9;p=thirdparty%2Fkernel%2Fstable-queue.git 5.15-stable patches added patches: drm-amd-display-avoid-reading-audio-pattern-past-audio_channels_count.patch drm-amdgpu-do-not-use-passthrough-mode-in-xen-dom0.patch firewire-core-extend-card-lock-in-fw_core_handle_bus_reset.patch firewire-fix-potential-uaf-in-outbound_phy_packet_callback.patch firewire-remove-check-of-list-iterator-against-head-past-the-loop-body.patch gpiolib-of-fix-bounds-check-for-gpio-reserved-ranges.patch iommu-arm-smmu-v3-fix-size-calculation-in-arm_smmu_mm_invalidate_range.patch iommu-vt-d-calculate-mask-for-non-aligned-flushes.patch kvm-x86-svm-account-for-family-17h-event-renumberings-in-amd_pmc_perf_hw_id.patch mmc-core-set-hs-clock-speed-before-sending-hs-cmd13.patch mmc-sdhci-msm-reset-gcc_sdcc_bcr-register-for-sdhc.patch mmc-sunxi-mmc-fix-dma-descriptors-allocated-above-32-bits.patch net-stmmac-disable-split-header-sph-for-intel-platforms.patch revert-sunrpc-attempt-af_local-connect-on-setup.patch risc-v-relocate-dtb-if-it-s-outside-memory-region.patch timekeeping-mark-nmi-safe-time-accessors-as-notrace.patch x86-fpu-prevent-fpu-state-corruption.patch --- diff --git a/queue-5.15/drm-amd-display-avoid-reading-audio-pattern-past-audio_channels_count.patch b/queue-5.15/drm-amd-display-avoid-reading-audio-pattern-past-audio_channels_count.patch new file mode 100644 index 00000000000..59ebdaffc52 --- /dev/null +++ b/queue-5.15/drm-amd-display-avoid-reading-audio-pattern-past-audio_channels_count.patch @@ -0,0 +1,33 @@ +From 3dfe85fa87b2a26bdbd292b66653bba065cf9941 Mon Sep 17 00:00:00 2001 +From: Harry Wentland +Date: Tue, 19 Apr 2022 13:03:12 -0400 +Subject: drm/amd/display: Avoid reading audio pattern past AUDIO_CHANNELS_COUNT + +From: Harry Wentland + +commit 3dfe85fa87b2a26bdbd292b66653bba065cf9941 upstream. + +A faulty receiver might report an erroneous channel count. We +should guard against reading beyond AUDIO_CHANNELS_COUNT as +that would overflow the dpcd_pattern_period array. + +Signed-off-by: Harry Wentland +Reviewed-by: Alex Deucher +Signed-off-by: Alex Deucher +Cc: stable@vger.kernel.org +Signed-off-by: Greg Kroah-Hartman +--- + drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c ++++ b/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c +@@ -3118,7 +3118,7 @@ static void dp_test_get_audio_test_data( + &dpcd_pattern_type.value, + sizeof(dpcd_pattern_type)); + +- channel_count = dpcd_test_mode.bits.channel_count + 1; ++ channel_count = min(dpcd_test_mode.bits.channel_count + 1, AUDIO_CHANNELS_COUNT); + + // read pattern periods for requested channels when sawTooth pattern is requested + if (dpcd_pattern_type.value == AUDIO_TEST_PATTERN_SAWTOOTH || diff --git a/queue-5.15/drm-amdgpu-do-not-use-passthrough-mode-in-xen-dom0.patch b/queue-5.15/drm-amdgpu-do-not-use-passthrough-mode-in-xen-dom0.patch new file mode 100644 index 00000000000..13924054d61 --- /dev/null +++ b/queue-5.15/drm-amdgpu-do-not-use-passthrough-mode-in-xen-dom0.patch @@ -0,0 +1,55 @@ +From 19965d8259fdabc6806da92adda49684f5bcbec5 Mon Sep 17 00:00:00 2001 +From: =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= + +Date: Wed, 27 Apr 2022 01:57:15 +0200 +Subject: drm/amdgpu: do not use passthrough mode in Xen dom0 +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Marek Marczykowski-Górecki + +commit 19965d8259fdabc6806da92adda49684f5bcbec5 upstream. + +While technically Xen dom0 is a virtual machine too, it does have +access to most of the hardware so it doesn't need to be considered a +"passthrough". Commit b818a5d37454 ("drm/amdgpu/gmc: use PCI BARs for +APUs in passthrough") changed how FB is accessed based on passthrough +mode. This breaks amdgpu in Xen dom0 with message like this: + + [drm:dc_dmub_srv_wait_idle [amdgpu]] *ERROR* Error waiting for DMUB idle: status=3 + +While the reason for this failure is unclear, the passthrough mode is +not really necessary in Xen dom0 anyway. So, to unbreak booting affected +kernels, disable passthrough mode in this case. + +Link: https://gitlab.freedesktop.org/drm/amd/-/issues/1985 +Fixes: b818a5d37454 ("drm/amdgpu/gmc: use PCI BARs for APUs in passthrough") +Signed-off-by: Marek Marczykowski-Górecki +Signed-off-by: Alex Deucher +Cc: stable@vger.kernel.org +Signed-off-by: Greg Kroah-Hartman +--- + drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c | 4 +++- + 1 file changed, 3 insertions(+), 1 deletion(-) + +--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c ++++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c +@@ -24,6 +24,7 @@ + #include + + #include ++#include + + #include "amdgpu.h" + #include "amdgpu_ras.h" +@@ -694,7 +695,8 @@ void amdgpu_detect_virtualization(struct + adev->virt.caps |= AMDGPU_SRIOV_CAPS_ENABLE_IOV; + + if (!reg) { +- if (is_virtual_machine()) /* passthrough mode exclus sriov mod */ ++ /* passthrough mode exclus sriov mod */ ++ if (is_virtual_machine() && !xen_initial_domain()) + adev->virt.caps |= AMDGPU_PASSTHROUGH_MODE; + } + diff --git a/queue-5.15/firewire-core-extend-card-lock-in-fw_core_handle_bus_reset.patch b/queue-5.15/firewire-core-extend-card-lock-in-fw_core_handle_bus_reset.patch new file mode 100644 index 00000000000..4825abb286c --- /dev/null +++ b/queue-5.15/firewire-core-extend-card-lock-in-fw_core_handle_bus_reset.patch @@ -0,0 +1,91 @@ +From a7ecbe92b9243edbe94772f6f2c854e4142a3345 Mon Sep 17 00:00:00 2001 +From: Niels Dossche +Date: Sat, 9 Apr 2022 13:12:43 +0900 +Subject: firewire: core: extend card->lock in fw_core_handle_bus_reset + +From: Niels Dossche + +commit a7ecbe92b9243edbe94772f6f2c854e4142a3345 upstream. + +card->local_node and card->bm_retries are both always accessed under +card->lock. +fw_core_handle_bus_reset has a check whose condition depends on +card->local_node and whose body writes to card->bm_retries. +Both of these accesses are not under card->lock. Move the lock acquiring +of card->lock to before this check such that these accesses do happen +when card->lock is held. +fw_destroy_nodes is called inside the check. +Since fw_destroy_nodes already acquires card->lock inside its function +body, move this out to the callsites of fw_destroy_nodes. +Also add a comment to indicate which locking is necessary when calling +fw_destroy_nodes. + +Cc: +Signed-off-by: Niels Dossche +Signed-off-by: Takashi Sakamoto +Link: https://lore.kernel.org/r/20220409041243.603210-4-o-takashi@sakamocchi.jp +Signed-off-by: Takashi Iwai +Signed-off-by: Greg Kroah-Hartman +--- + drivers/firewire/core-card.c | 3 +++ + drivers/firewire/core-topology.c | 9 +++------ + 2 files changed, 6 insertions(+), 6 deletions(-) + +--- a/drivers/firewire/core-card.c ++++ b/drivers/firewire/core-card.c +@@ -668,6 +668,7 @@ EXPORT_SYMBOL_GPL(fw_card_release); + void fw_core_remove_card(struct fw_card *card) + { + struct fw_card_driver dummy_driver = dummy_driver_template; ++ unsigned long flags; + + card->driver->update_phy_reg(card, 4, + PHY_LINK_ACTIVE | PHY_CONTENDER, 0); +@@ -682,7 +683,9 @@ void fw_core_remove_card(struct fw_card + dummy_driver.stop_iso = card->driver->stop_iso; + card->driver = &dummy_driver; + ++ spin_lock_irqsave(&card->lock, flags); + fw_destroy_nodes(card); ++ spin_unlock_irqrestore(&card->lock, flags); + + /* Wait for all users, especially device workqueue jobs, to finish. */ + fw_card_put(card); +--- a/drivers/firewire/core-topology.c ++++ b/drivers/firewire/core-topology.c +@@ -375,16 +375,13 @@ static void report_found_node(struct fw_ + card->bm_retries = 0; + } + ++/* Must be called with card->lock held */ + void fw_destroy_nodes(struct fw_card *card) + { +- unsigned long flags; +- +- spin_lock_irqsave(&card->lock, flags); + card->color++; + if (card->local_node != NULL) + for_each_fw_node(card, card->local_node, report_lost_node); + card->local_node = NULL; +- spin_unlock_irqrestore(&card->lock, flags); + } + + static void move_tree(struct fw_node *node0, struct fw_node *node1, int port) +@@ -510,6 +507,8 @@ void fw_core_handle_bus_reset(struct fw_ + struct fw_node *local_node; + unsigned long flags; + ++ spin_lock_irqsave(&card->lock, flags); ++ + /* + * If the selfID buffer is not the immediate successor of the + * previously processed one, we cannot reliably compare the +@@ -521,8 +520,6 @@ void fw_core_handle_bus_reset(struct fw_ + card->bm_retries = 0; + } + +- spin_lock_irqsave(&card->lock, flags); +- + card->broadcast_channel_allocated = card->broadcast_channel_auto_allocated; + card->node_id = node_id; + /* diff --git a/queue-5.15/firewire-fix-potential-uaf-in-outbound_phy_packet_callback.patch b/queue-5.15/firewire-fix-potential-uaf-in-outbound_phy_packet_callback.patch new file mode 100644 index 00000000000..f63a9c9154b --- /dev/null +++ b/queue-5.15/firewire-fix-potential-uaf-in-outbound_phy_packet_callback.patch @@ -0,0 +1,47 @@ +From b7c81f80246fac44077166f3e07103affe6db8ff Mon Sep 17 00:00:00 2001 +From: Chengfeng Ye +Date: Sat, 9 Apr 2022 13:12:41 +0900 +Subject: firewire: fix potential uaf in outbound_phy_packet_callback() + +From: Chengfeng Ye + +commit b7c81f80246fac44077166f3e07103affe6db8ff upstream. + +&e->event and e point to the same address, and &e->event could +be freed in queue_event. So there is a potential uaf issue if +we dereference e after calling queue_event(). Fix this by adding +a temporary variable to maintain e->client in advance, this can +avoid the potential uaf issue. + +Cc: +Signed-off-by: Chengfeng Ye +Signed-off-by: Takashi Sakamoto +Link: https://lore.kernel.org/r/20220409041243.603210-2-o-takashi@sakamocchi.jp +Signed-off-by: Takashi Iwai +Signed-off-by: Greg Kroah-Hartman +--- + drivers/firewire/core-cdev.c | 4 +++- + 1 file changed, 3 insertions(+), 1 deletion(-) + +--- a/drivers/firewire/core-cdev.c ++++ b/drivers/firewire/core-cdev.c +@@ -1480,6 +1480,7 @@ static void outbound_phy_packet_callback + { + struct outbound_phy_packet_event *e = + container_of(packet, struct outbound_phy_packet_event, p); ++ struct client *e_client; + + switch (status) { + /* expected: */ +@@ -1496,9 +1497,10 @@ static void outbound_phy_packet_callback + } + e->phy_packet.data[0] = packet->timestamp; + ++ e_client = e->client; + queue_event(e->client, &e->event, &e->phy_packet, + sizeof(e->phy_packet) + e->phy_packet.length, NULL, 0); +- client_put(e->client); ++ client_put(e_client); + } + + static int ioctl_send_phy_packet(struct client *client, union ioctl_arg *arg) diff --git a/queue-5.15/firewire-remove-check-of-list-iterator-against-head-past-the-loop-body.patch b/queue-5.15/firewire-remove-check-of-list-iterator-against-head-past-the-loop-body.patch new file mode 100644 index 00000000000..830383d938d --- /dev/null +++ b/queue-5.15/firewire-remove-check-of-list-iterator-against-head-past-the-loop-body.patch @@ -0,0 +1,140 @@ +From 9423973869bd4632ffe669f950510c49296656e0 Mon Sep 17 00:00:00 2001 +From: Jakob Koschel +Date: Sat, 9 Apr 2022 13:12:42 +0900 +Subject: firewire: remove check of list iterator against head past the loop body + +From: Jakob Koschel + +commit 9423973869bd4632ffe669f950510c49296656e0 upstream. + +When list_for_each_entry() completes the iteration over the whole list +without breaking the loop, the iterator value will be a bogus pointer +computed based on the head element. + +While it is safe to use the pointer to determine if it was computed +based on the head element, either with list_entry_is_head() or +&pos->member == head, using the iterator variable after the loop should +be avoided. + +In preparation to limit the scope of a list iterator to the list +traversal loop, use a dedicated pointer to point to the found element [1]. + +Link: https://lore.kernel.org/all/CAHk-=wgRr_D8CB-D9Kg-c=EHreAsk5SqXPwr9Y7k9sA6cWXJ6w@mail.gmail.com/ [1] +Cc: +Signed-off-by: Jakob Koschel +Signed-off-by: Takashi Sakamoto +Link: https://lore.kernel.org/r/20220409041243.603210-3-o-takashi@sakamocchi.jp +Signed-off-by: Takashi Iwai +Signed-off-by: Greg Kroah-Hartman +--- + drivers/firewire/core-transaction.c | 30 ++++++++++++++++-------------- + drivers/firewire/sbp2.c | 13 +++++++------ + 2 files changed, 23 insertions(+), 20 deletions(-) + +--- a/drivers/firewire/core-transaction.c ++++ b/drivers/firewire/core-transaction.c +@@ -73,24 +73,25 @@ static int try_cancel_split_timeout(stru + static int close_transaction(struct fw_transaction *transaction, + struct fw_card *card, int rcode) + { +- struct fw_transaction *t; ++ struct fw_transaction *t = NULL, *iter; + unsigned long flags; + + spin_lock_irqsave(&card->lock, flags); +- list_for_each_entry(t, &card->transaction_list, link) { +- if (t == transaction) { +- if (!try_cancel_split_timeout(t)) { ++ list_for_each_entry(iter, &card->transaction_list, link) { ++ if (iter == transaction) { ++ if (!try_cancel_split_timeout(iter)) { + spin_unlock_irqrestore(&card->lock, flags); + goto timed_out; + } +- list_del_init(&t->link); +- card->tlabel_mask &= ~(1ULL << t->tlabel); ++ list_del_init(&iter->link); ++ card->tlabel_mask &= ~(1ULL << iter->tlabel); ++ t = iter; + break; + } + } + spin_unlock_irqrestore(&card->lock, flags); + +- if (&t->link != &card->transaction_list) { ++ if (t) { + t->callback(card, rcode, NULL, 0, t->callback_data); + return 0; + } +@@ -935,7 +936,7 @@ EXPORT_SYMBOL(fw_core_handle_request); + + void fw_core_handle_response(struct fw_card *card, struct fw_packet *p) + { +- struct fw_transaction *t; ++ struct fw_transaction *t = NULL, *iter; + unsigned long flags; + u32 *data; + size_t data_length; +@@ -947,20 +948,21 @@ void fw_core_handle_response(struct fw_c + rcode = HEADER_GET_RCODE(p->header[1]); + + spin_lock_irqsave(&card->lock, flags); +- list_for_each_entry(t, &card->transaction_list, link) { +- if (t->node_id == source && t->tlabel == tlabel) { +- if (!try_cancel_split_timeout(t)) { ++ list_for_each_entry(iter, &card->transaction_list, link) { ++ if (iter->node_id == source && iter->tlabel == tlabel) { ++ if (!try_cancel_split_timeout(iter)) { + spin_unlock_irqrestore(&card->lock, flags); + goto timed_out; + } +- list_del_init(&t->link); +- card->tlabel_mask &= ~(1ULL << t->tlabel); ++ list_del_init(&iter->link); ++ card->tlabel_mask &= ~(1ULL << iter->tlabel); ++ t = iter; + break; + } + } + spin_unlock_irqrestore(&card->lock, flags); + +- if (&t->link == &card->transaction_list) { ++ if (!t) { + timed_out: + fw_notice(card, "unsolicited response (source %x, tlabel %x)\n", + source, tlabel); +--- a/drivers/firewire/sbp2.c ++++ b/drivers/firewire/sbp2.c +@@ -408,7 +408,7 @@ static void sbp2_status_write(struct fw_ + void *payload, size_t length, void *callback_data) + { + struct sbp2_logical_unit *lu = callback_data; +- struct sbp2_orb *orb; ++ struct sbp2_orb *orb = NULL, *iter; + struct sbp2_status status; + unsigned long flags; + +@@ -433,17 +433,18 @@ static void sbp2_status_write(struct fw_ + + /* Lookup the orb corresponding to this status write. */ + spin_lock_irqsave(&lu->tgt->lock, flags); +- list_for_each_entry(orb, &lu->orb_list, link) { ++ list_for_each_entry(iter, &lu->orb_list, link) { + if (STATUS_GET_ORB_HIGH(status) == 0 && +- STATUS_GET_ORB_LOW(status) == orb->request_bus) { +- orb->rcode = RCODE_COMPLETE; +- list_del(&orb->link); ++ STATUS_GET_ORB_LOW(status) == iter->request_bus) { ++ iter->rcode = RCODE_COMPLETE; ++ list_del(&iter->link); ++ orb = iter; + break; + } + } + spin_unlock_irqrestore(&lu->tgt->lock, flags); + +- if (&orb->link != &lu->orb_list) { ++ if (orb) { + orb->callback(orb, &status); + kref_put(&orb->kref, free_orb); /* orb callback reference */ + } else { diff --git a/queue-5.15/gpiolib-of-fix-bounds-check-for-gpio-reserved-ranges.patch b/queue-5.15/gpiolib-of-fix-bounds-check-for-gpio-reserved-ranges.patch new file mode 100644 index 00000000000..aeca90b72c4 --- /dev/null +++ b/queue-5.15/gpiolib-of-fix-bounds-check-for-gpio-reserved-ranges.patch @@ -0,0 +1,47 @@ +From e75f88efac05bf4e107e4171d8db6d8c3937252d Mon Sep 17 00:00:00 2001 +From: Andrei Lalaev +Date: Fri, 15 Apr 2022 10:07:11 +0300 +Subject: gpiolib: of: fix bounds check for 'gpio-reserved-ranges' + +From: Andrei Lalaev + +commit e75f88efac05bf4e107e4171d8db6d8c3937252d upstream. + +Gpiolib interprets the elements of "gpio-reserved-ranges" as "start,size" +because it clears "size" bits starting from the "start" bit in the according +bitmap. So it has to use "greater" instead of "greater or equal" when performs +bounds check to make sure that GPIOs are in the available range. +Previous implementation skipped ranges that include the last GPIO in +the range. + +I wrote the mail to the maintainers +(https://lore.kernel.org/linux-gpio/20220412115554.159435-1-andrei.lalaev@emlid.com/T/#u) +of the questioned DTSes (because I couldn't understand how the maintainers +interpreted this property), but I haven't received a response. +Since the questioned DTSes use "gpio-reserved-ranges = <0 4>" +(i.e., the beginning of the range), this patch doesn't affect these DTSes at all. +TBH this patch doesn't break any existing DTSes because none of them +reserve gpios at the end of range. + +Fixes: 726cb3ba4969 ("gpiolib: Support 'gpio-reserved-ranges' property") +Signed-off-by: Andrei Lalaev +Reviewed-by: Andy Shevchenko +Reviewed-by: Linus Walleij +Cc: stable@vger.kernel.org +Signed-off-by: Bartosz Golaszewski +Signed-off-by: Greg Kroah-Hartman +--- + drivers/gpio/gpiolib-of.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/gpio/gpiolib-of.c ++++ b/drivers/gpio/gpiolib-of.c +@@ -912,7 +912,7 @@ static void of_gpiochip_init_valid_mask( + i, &start); + of_property_read_u32_index(np, "gpio-reserved-ranges", + i + 1, &count); +- if (start >= chip->ngpio || start + count >= chip->ngpio) ++ if (start >= chip->ngpio || start + count > chip->ngpio) + continue; + + bitmap_clear(chip->valid_mask, start, count); diff --git a/queue-5.15/iommu-arm-smmu-v3-fix-size-calculation-in-arm_smmu_mm_invalidate_range.patch b/queue-5.15/iommu-arm-smmu-v3-fix-size-calculation-in-arm_smmu_mm_invalidate_range.patch new file mode 100644 index 00000000000..3d161f32b63 --- /dev/null +++ b/queue-5.15/iommu-arm-smmu-v3-fix-size-calculation-in-arm_smmu_mm_invalidate_range.patch @@ -0,0 +1,57 @@ +From 95d4782c34a60800ccf91d9f0703137d4367a2fc Mon Sep 17 00:00:00 2001 +From: Nicolin Chen +Date: Tue, 19 Apr 2022 14:01:58 -0700 +Subject: iommu/arm-smmu-v3: Fix size calculation in arm_smmu_mm_invalidate_range() + +From: Nicolin Chen + +commit 95d4782c34a60800ccf91d9f0703137d4367a2fc upstream. + +The arm_smmu_mm_invalidate_range function is designed to be called +by mm core for Shared Virtual Addressing purpose between IOMMU and +CPU MMU. However, the ways of two subsystems defining their "end" +addresses are slightly different. IOMMU defines its "end" address +using the last address of an address range, while mm core defines +that using the following address of an address range: + + include/linux/mm_types.h: + unsigned long vm_end; + /* The first byte after our end address ... + +This mismatch resulted in an incorrect calculation for size so it +failed to be page-size aligned. Further, it caused a dead loop at +"while (iova < end)" check in __arm_smmu_tlb_inv_range function. + +This patch fixes the issue by doing the calculation correctly. + +Fixes: 2f7e8c553e98 ("iommu/arm-smmu-v3: Hook up ATC invalidation to mm ops") +Cc: stable@vger.kernel.org +Signed-off-by: Nicolin Chen +Reviewed-by: Jason Gunthorpe +Reviewed-by: Robin Murphy +Reviewed-by: Jean-Philippe Brucker +Link: https://lore.kernel.org/r/20220419210158.21320-1-nicolinc@nvidia.com +Signed-off-by: Will Deacon +Signed-off-by: Greg Kroah-Hartman +--- + drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c | 9 ++++++++- + 1 file changed, 8 insertions(+), 1 deletion(-) + +--- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c ++++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c +@@ -183,7 +183,14 @@ static void arm_smmu_mm_invalidate_range + { + struct arm_smmu_mmu_notifier *smmu_mn = mn_to_smmu(mn); + struct arm_smmu_domain *smmu_domain = smmu_mn->domain; +- size_t size = end - start + 1; ++ size_t size; ++ ++ /* ++ * The mm_types defines vm_end as the first byte after the end address, ++ * different from IOMMU subsystem using the last address of an address ++ * range. So do a simple translation here by calculating size correctly. ++ */ ++ size = end - start; + + if (!(smmu_domain->smmu->features & ARM_SMMU_FEAT_BTM)) + arm_smmu_tlb_inv_range_asid(start, size, smmu_mn->cd->asid, diff --git a/queue-5.15/iommu-vt-d-calculate-mask-for-non-aligned-flushes.patch b/queue-5.15/iommu-vt-d-calculate-mask-for-non-aligned-flushes.patch new file mode 100644 index 00000000000..b5fc7918099 --- /dev/null +++ b/queue-5.15/iommu-vt-d-calculate-mask-for-non-aligned-flushes.patch @@ -0,0 +1,85 @@ +From 59bf3557cf2f8a469a554aea1e3d2c8e72a579f7 Mon Sep 17 00:00:00 2001 +From: David Stevens +Date: Sun, 10 Apr 2022 09:35:33 +0800 +Subject: iommu/vt-d: Calculate mask for non-aligned flushes + +From: David Stevens + +commit 59bf3557cf2f8a469a554aea1e3d2c8e72a579f7 upstream. + +Calculate the appropriate mask for non-size-aligned page selective +invalidation. Since psi uses the mask value to mask out the lower order +bits of the target address, properly flushing the iotlb requires using a +mask value such that [pfn, pfn+pages) all lie within the flushed +size-aligned region. This is not normally an issue because iova.c +always allocates iovas that are aligned to their size. However, iovas +which come from other sources (e.g. userspace via VFIO) may not be +aligned. + +To properly flush the IOTLB, both the start and end pfns need to be +equal after applying the mask. That means that the most efficient mask +to use is the index of the lowest bit that is equal where all higher +bits are also equal. For example, if pfn=0x17f and pages=3, then +end_pfn=0x181, so the smallest mask we can use is 8. Any differences +above the highest bit of pages are due to carrying, so by xnor'ing pfn +and end_pfn and then masking out the lower order bits based on pages, we +get 0xffffff00, where the first set bit is the mask we want to use. + +Fixes: 6fe1010d6d9c ("vfio/type1: DMA unmap chunking") +Cc: stable@vger.kernel.org +Signed-off-by: David Stevens +Reviewed-by: Kevin Tian +Link: https://lore.kernel.org/r/20220401022430.1262215-1-stevensd@google.com +Signed-off-by: Lu Baolu +Link: https://lore.kernel.org/r/20220410013533.3959168-2-baolu.lu@linux.intel.com +Signed-off-by: Joerg Roedel +Signed-off-by: Greg Kroah-Hartman +--- + drivers/iommu/intel/iommu.c | 27 ++++++++++++++++++++++++--- + 1 file changed, 24 insertions(+), 3 deletions(-) + +--- a/drivers/iommu/intel/iommu.c ++++ b/drivers/iommu/intel/iommu.c +@@ -1637,7 +1637,8 @@ static void iommu_flush_iotlb_psi(struct + unsigned long pfn, unsigned int pages, + int ih, int map) + { +- unsigned int mask = ilog2(__roundup_pow_of_two(pages)); ++ unsigned int aligned_pages = __roundup_pow_of_two(pages); ++ unsigned int mask = ilog2(aligned_pages); + uint64_t addr = (uint64_t)pfn << VTD_PAGE_SHIFT; + u16 did = domain->iommu_did[iommu->seq_id]; + +@@ -1649,10 +1650,30 @@ static void iommu_flush_iotlb_psi(struct + if (domain_use_first_level(domain)) { + domain_flush_piotlb(iommu, domain, addr, pages, ih); + } else { ++ unsigned long bitmask = aligned_pages - 1; ++ ++ /* ++ * PSI masks the low order bits of the base address. If the ++ * address isn't aligned to the mask, then compute a mask value ++ * needed to ensure the target range is flushed. ++ */ ++ if (unlikely(bitmask & pfn)) { ++ unsigned long end_pfn = pfn + pages - 1, shared_bits; ++ ++ /* ++ * Since end_pfn <= pfn + bitmask, the only way bits ++ * higher than bitmask can differ in pfn and end_pfn is ++ * by carrying. This means after masking out bitmask, ++ * high bits starting with the first set bit in ++ * shared_bits are all equal in both pfn and end_pfn. ++ */ ++ shared_bits = ~(pfn ^ end_pfn) & ~bitmask; ++ mask = shared_bits ? __ffs(shared_bits) : BITS_PER_LONG; ++ } ++ + /* + * Fallback to domain selective flush if no PSI support or +- * the size is too big. PSI requires page size to be 2 ^ x, +- * and the base address is naturally aligned to the size. ++ * the size is too big. + */ + if (!cap_pgsel_inv(iommu->cap) || + mask > cap_max_amask_val(iommu->cap)) diff --git a/queue-5.15/kvm-x86-svm-account-for-family-17h-event-renumberings-in-amd_pmc_perf_hw_id.patch b/queue-5.15/kvm-x86-svm-account-for-family-17h-event-renumberings-in-amd_pmc_perf_hw_id.patch new file mode 100644 index 00000000000..da6e56265b4 --- /dev/null +++ b/queue-5.15/kvm-x86-svm-account-for-family-17h-event-renumberings-in-amd_pmc_perf_hw_id.patch @@ -0,0 +1,84 @@ +From 5eb849322d7f7ae9d5c587c7bc3b4f7c6872cd2f Mon Sep 17 00:00:00 2001 +From: Kyle Huey +Date: Mon, 2 May 2022 22:01:36 -0700 +Subject: KVM: x86/svm: Account for family 17h event renumberings in amd_pmc_perf_hw_id + +From: Kyle Huey + +commit 5eb849322d7f7ae9d5c587c7bc3b4f7c6872cd2f upstream. + +Zen renumbered some of the performance counters that correspond to the +well known events in perf_hw_id. This code in KVM was never updated for +that, so guest that attempt to use counters on Zen that correspond to the +pre-Zen perf_hw_id values will silently receive the wrong values. + +This has been observed in the wild with rr[0] when running in Zen 3 +guests. rr uses the retired conditional branch counter 00d1 which is +incorrectly recognized by KVM as PERF_COUNT_HW_STALLED_CYCLES_BACKEND. + +[0] https://rr-project.org/ + +Signed-off-by: Kyle Huey +Message-Id: <20220503050136.86298-1-khuey@kylehuey.com> +Cc: stable@vger.kernel.org +[Check guest family, not host. - Paolo] +Signed-off-by: Paolo Bonzini +Signed-off-by: Greg Kroah-Hartman +--- + arch/x86/kvm/svm/pmu.c | 28 +++++++++++++++++++++++++--- + 1 file changed, 25 insertions(+), 3 deletions(-) + +--- a/arch/x86/kvm/svm/pmu.c ++++ b/arch/x86/kvm/svm/pmu.c +@@ -44,6 +44,22 @@ static struct kvm_event_hw_type_mapping + [7] = { 0xd1, 0x00, PERF_COUNT_HW_STALLED_CYCLES_BACKEND }, + }; + ++/* duplicated from amd_f17h_perfmon_event_map. */ ++static struct kvm_event_hw_type_mapping amd_f17h_event_mapping[] = { ++ [0] = { 0x76, 0x00, PERF_COUNT_HW_CPU_CYCLES }, ++ [1] = { 0xc0, 0x00, PERF_COUNT_HW_INSTRUCTIONS }, ++ [2] = { 0x60, 0xff, PERF_COUNT_HW_CACHE_REFERENCES }, ++ [3] = { 0x64, 0x09, PERF_COUNT_HW_CACHE_MISSES }, ++ [4] = { 0xc2, 0x00, PERF_COUNT_HW_BRANCH_INSTRUCTIONS }, ++ [5] = { 0xc3, 0x00, PERF_COUNT_HW_BRANCH_MISSES }, ++ [6] = { 0x87, 0x02, PERF_COUNT_HW_STALLED_CYCLES_FRONTEND }, ++ [7] = { 0x87, 0x01, PERF_COUNT_HW_STALLED_CYCLES_BACKEND }, ++}; ++ ++/* amd_pmc_perf_hw_id depends on these being the same size */ ++static_assert(ARRAY_SIZE(amd_event_mapping) == ++ ARRAY_SIZE(amd_f17h_event_mapping)); ++ + static unsigned int get_msr_base(struct kvm_pmu *pmu, enum pmu_type type) + { + struct kvm_vcpu *vcpu = pmu_to_vcpu(pmu); +@@ -136,19 +152,25 @@ static inline struct kvm_pmc *get_gp_pmc + + static unsigned int amd_pmc_perf_hw_id(struct kvm_pmc *pmc) + { ++ struct kvm_event_hw_type_mapping *event_mapping; + u8 event_select = pmc->eventsel & ARCH_PERFMON_EVENTSEL_EVENT; + u8 unit_mask = (pmc->eventsel & ARCH_PERFMON_EVENTSEL_UMASK) >> 8; + int i; + ++ if (guest_cpuid_family(pmc->vcpu) >= 0x17) ++ event_mapping = amd_f17h_event_mapping; ++ else ++ event_mapping = amd_event_mapping; ++ + for (i = 0; i < ARRAY_SIZE(amd_event_mapping); i++) +- if (amd_event_mapping[i].eventsel == event_select +- && amd_event_mapping[i].unit_mask == unit_mask) ++ if (event_mapping[i].eventsel == event_select ++ && event_mapping[i].unit_mask == unit_mask) + break; + + if (i == ARRAY_SIZE(amd_event_mapping)) + return PERF_COUNT_HW_MAX; + +- return amd_event_mapping[i].event_type; ++ return event_mapping[i].event_type; + } + + /* return PERF_COUNT_HW_MAX as AMD doesn't have fixed events */ diff --git a/queue-5.15/mmc-core-set-hs-clock-speed-before-sending-hs-cmd13.patch b/queue-5.15/mmc-core-set-hs-clock-speed-before-sending-hs-cmd13.patch new file mode 100644 index 00000000000..c722e0fdf90 --- /dev/null +++ b/queue-5.15/mmc-core-set-hs-clock-speed-before-sending-hs-cmd13.patch @@ -0,0 +1,131 @@ +From 4bc31edebde51fcf8ad0794763b8679a7ecb5ec0 Mon Sep 17 00:00:00 2001 +From: Brian Norris +Date: Fri, 22 Apr 2022 10:08:53 -0700 +Subject: mmc: core: Set HS clock speed before sending HS CMD13 + +From: Brian Norris + +commit 4bc31edebde51fcf8ad0794763b8679a7ecb5ec0 upstream. + +Way back in commit 4f25580fb84d ("mmc: core: changes frequency to +hs_max_dtr when selecting hs400es"), Rockchip engineers noticed that +some eMMC don't respond to SEND_STATUS commands very reliably if they're +still running at a low initial frequency. As mentioned in that commit, +JESD84-B51 P49 suggests a sequence in which the host: +1. sets HS_TIMING +2. bumps the clock ("<= 52 MHz") +3. sends further commands + +It doesn't exactly require that we don't use a lower-than-52MHz +frequency, but in practice, these eMMC don't like it. + +The aforementioned commit tried to get that right for HS400ES, although +it's unclear whether this ever truly worked as committed into mainline, +as other changes/refactoring adjusted the sequence in conflicting ways: + +08573eaf1a70 ("mmc: mmc: do not use CMD13 to get status after speed mode +switch") + +53e60650f74e ("mmc: core: Allow CMD13 polling when switching to HS mode +for mmc") + +In any case, today we do step 3 before step 2. Let's fix that, and also +apply the same logic to HS200/400, where this eMMC has problems too. + +Resolves errors like this seen when booting some RK3399 Gru/Scarlet +systems: + +[ 2.058881] mmc1: CQHCI version 5.10 +[ 2.097545] mmc1: SDHCI controller on fe330000.mmc [fe330000.mmc] using ADMA +[ 2.209804] mmc1: mmc_select_hs400es failed, error -84 +[ 2.215597] mmc1: error -84 whilst initialising MMC card +[ 2.417514] mmc1: mmc_select_hs400es failed, error -110 +[ 2.423373] mmc1: error -110 whilst initialising MMC card +[ 2.605052] mmc1: mmc_select_hs400es failed, error -110 +[ 2.617944] mmc1: error -110 whilst initialising MMC card +[ 2.835884] mmc1: mmc_select_hs400es failed, error -110 +[ 2.841751] mmc1: error -110 whilst initialising MMC card + +Ealier versions of this patch bumped to 200MHz/HS200 speeds too early, +which caused issues on, e.g., qcom-msm8974-fairphone-fp2. (Thanks for +the report Luca!) After a second look, it appears that aligns with +JESD84 / page 45 / table 28, so we need to keep to lower (HS / 52 MHz) +rates first. + +Fixes: 08573eaf1a70 ("mmc: mmc: do not use CMD13 to get status after speed mode switch") +Fixes: 53e60650f74e ("mmc: core: Allow CMD13 polling when switching to HS mode for mmc") +Fixes: 4f25580fb84d ("mmc: core: changes frequency to hs_max_dtr when selecting hs400es") +Cc: Shawn Lin +Link: https://lore.kernel.org/linux-mmc/11962455.O9o76ZdvQC@g550jk/ +Reported-by: Luca Weiss +Signed-off-by: Brian Norris +Tested-by: Luca Weiss +Cc: stable@vger.kernel.org +Link: https://lore.kernel.org/r/20220422100824.v4.1.I484f4ee35609f78b932bd50feed639c29e64997e@changeid +Signed-off-by: Ulf Hansson +Signed-off-by: Greg Kroah-Hartman +--- + drivers/mmc/core/mmc.c | 23 +++++++++++++++++++---- + 1 file changed, 19 insertions(+), 4 deletions(-) + +--- a/drivers/mmc/core/mmc.c ++++ b/drivers/mmc/core/mmc.c +@@ -1381,13 +1381,17 @@ static int mmc_select_hs400es(struct mmc + goto out_err; + } + ++ /* ++ * Bump to HS timing and frequency. Some cards don't handle ++ * SEND_STATUS reliably at the initial frequency. ++ */ + mmc_set_timing(host, MMC_TIMING_MMC_HS); ++ mmc_set_bus_speed(card); ++ + err = mmc_switch_status(card, true); + if (err) + goto out_err; + +- mmc_set_clock(host, card->ext_csd.hs_max_dtr); +- + /* Switch card to DDR with strobe bit */ + val = EXT_CSD_DDR_BUS_WIDTH_8 | EXT_CSD_BUS_WIDTH_STROBE; + err = mmc_switch(card, EXT_CSD_CMD_SET_NORMAL, +@@ -1445,7 +1449,7 @@ out_err: + static int mmc_select_hs200(struct mmc_card *card) + { + struct mmc_host *host = card->host; +- unsigned int old_timing, old_signal_voltage; ++ unsigned int old_timing, old_signal_voltage, old_clock; + int err = -EINVAL; + u8 val; + +@@ -1476,8 +1480,17 @@ static int mmc_select_hs200(struct mmc_c + false, true, MMC_CMD_RETRIES); + if (err) + goto err; ++ ++ /* ++ * Bump to HS timing and frequency. Some cards don't handle ++ * SEND_STATUS reliably at the initial frequency. ++ * NB: We can't move to full (HS200) speeds until after we've ++ * successfully switched over. ++ */ + old_timing = host->ios.timing; ++ old_clock = host->ios.clock; + mmc_set_timing(host, MMC_TIMING_MMC_HS200); ++ mmc_set_clock(card->host, card->ext_csd.hs_max_dtr); + + /* + * For HS200, CRC errors are not a reliable way to know the +@@ -1490,8 +1503,10 @@ static int mmc_select_hs200(struct mmc_c + * mmc_select_timing() assumes timing has not changed if + * it is a switch error. + */ +- if (err == -EBADMSG) ++ if (err == -EBADMSG) { ++ mmc_set_clock(host, old_clock); + mmc_set_timing(host, old_timing); ++ } + } + err: + if (err) { diff --git a/queue-5.15/mmc-sdhci-msm-reset-gcc_sdcc_bcr-register-for-sdhc.patch b/queue-5.15/mmc-sdhci-msm-reset-gcc_sdcc_bcr-register-for-sdhc.patch new file mode 100644 index 00000000000..62e961b2390 --- /dev/null +++ b/queue-5.15/mmc-sdhci-msm-reset-gcc_sdcc_bcr-register-for-sdhc.patch @@ -0,0 +1,112 @@ +From 3e5a8e8494a8122fe4eb3f167662f406cab753b9 Mon Sep 17 00:00:00 2001 +From: Shaik Sajida Bhanu +Date: Sun, 24 Apr 2022 21:32:33 +0530 +Subject: mmc: sdhci-msm: Reset GCC_SDCC_BCR register for SDHC + +From: Shaik Sajida Bhanu + +commit 3e5a8e8494a8122fe4eb3f167662f406cab753b9 upstream. + +Reset GCC_SDCC_BCR register before every fresh initilazation. This will +reset whole SDHC-msm controller, clears the previous power control +states and avoids, software reset timeout issues as below. + +[ 5.458061][ T262] mmc1: Reset 0x1 never completed. +[ 5.462454][ T262] mmc1: sdhci: ============ SDHCI REGISTER DUMP =========== +[ 5.469065][ T262] mmc1: sdhci: Sys addr: 0x00000000 | Version: 0x00007202 +[ 5.475688][ T262] mmc1: sdhci: Blk size: 0x00000000 | Blk cnt: 0x00000000 +[ 5.482315][ T262] mmc1: sdhci: Argument: 0x00000000 | Trn mode: 0x00000000 +[ 5.488927][ T262] mmc1: sdhci: Present: 0x01f800f0 | Host ctl: 0x00000000 +[ 5.495539][ T262] mmc1: sdhci: Power: 0x00000000 | Blk gap: 0x00000000 +[ 5.502162][ T262] mmc1: sdhci: Wake-up: 0x00000000 | Clock: 0x00000003 +[ 5.508768][ T262] mmc1: sdhci: Timeout: 0x00000000 | Int stat: 0x00000000 +[ 5.515381][ T262] mmc1: sdhci: Int enab: 0x00000000 | Sig enab: 0x00000000 +[ 5.521996][ T262] mmc1: sdhci: ACmd stat: 0x00000000 | Slot int: 0x00000000 +[ 5.528607][ T262] mmc1: sdhci: Caps: 0x362dc8b2 | Caps_1: 0x0000808f +[ 5.535227][ T262] mmc1: sdhci: Cmd: 0x00000000 | Max curr: 0x00000000 +[ 5.541841][ T262] mmc1: sdhci: Resp[0]: 0x00000000 | Resp[1]: 0x00000000 +[ 5.548454][ T262] mmc1: sdhci: Resp[2]: 0x00000000 | Resp[3]: 0x00000000 +[ 5.555079][ T262] mmc1: sdhci: Host ctl2: 0x00000000 +[ 5.559651][ T262] mmc1: sdhci_msm: ----------- VENDOR REGISTER DUMP----------- +[ 5.566621][ T262] mmc1: sdhci_msm: DLL sts: 0x00000000 | DLL cfg: 0x6000642c | DLL cfg2: 0x0020a000 +[ 5.575465][ T262] mmc1: sdhci_msm: DLL cfg3: 0x00000000 | DLL usr ctl: 0x00010800 | DDR cfg: 0x80040873 +[ 5.584658][ T262] mmc1: sdhci_msm: Vndr func: 0x00018a9c | Vndr func2 : 0xf88218a8 Vndr func3: 0x02626040 + +Fixes: 0eb0d9f4de34 ("mmc: sdhci-msm: Initial support for Qualcomm chipsets") +Signed-off-by: Shaik Sajida Bhanu +Acked-by: Adrian Hunter +Reviewed-by: Philipp Zabel +Tested-by: Konrad Dybcio +Cc: stable@vger.kernel.org +Link: https://lore.kernel.org/r/1650816153-23797-1-git-send-email-quic_c_sbhanu@quicinc.com +Signed-off-by: Ulf Hansson +Signed-off-by: Greg Kroah-Hartman +--- + drivers/mmc/host/sdhci-msm.c | 42 ++++++++++++++++++++++++++++++++++++++++++ + 1 file changed, 42 insertions(+) + +--- a/drivers/mmc/host/sdhci-msm.c ++++ b/drivers/mmc/host/sdhci-msm.c +@@ -17,6 +17,7 @@ + #include + #include + #include ++#include + + #include "sdhci-pltfm.h" + #include "cqhci.h" +@@ -2482,6 +2483,43 @@ static inline void sdhci_msm_get_of_prop + of_property_read_u32(node, "qcom,dll-config", &msm_host->dll_config); + } + ++static int sdhci_msm_gcc_reset(struct device *dev, struct sdhci_host *host) ++{ ++ struct reset_control *reset; ++ int ret = 0; ++ ++ reset = reset_control_get_optional_exclusive(dev, NULL); ++ if (IS_ERR(reset)) ++ return dev_err_probe(dev, PTR_ERR(reset), ++ "unable to acquire core_reset\n"); ++ ++ if (!reset) ++ return ret; ++ ++ ret = reset_control_assert(reset); ++ if (ret) { ++ reset_control_put(reset); ++ return dev_err_probe(dev, ret, "core_reset assert failed\n"); ++ } ++ ++ /* ++ * The hardware requirement for delay between assert/deassert ++ * is at least 3-4 sleep clock (32.7KHz) cycles, which comes to ++ * ~125us (4/32768). To be on the safe side add 200us delay. ++ */ ++ usleep_range(200, 210); ++ ++ ret = reset_control_deassert(reset); ++ if (ret) { ++ reset_control_put(reset); ++ return dev_err_probe(dev, ret, "core_reset deassert failed\n"); ++ } ++ ++ usleep_range(200, 210); ++ reset_control_put(reset); ++ ++ return ret; ++} + + static int sdhci_msm_probe(struct platform_device *pdev) + { +@@ -2529,6 +2567,10 @@ static int sdhci_msm_probe(struct platfo + + msm_host->saved_tuning_phase = INVALID_TUNING_PHASE; + ++ ret = sdhci_msm_gcc_reset(&pdev->dev, host); ++ if (ret) ++ goto pltfm_free; ++ + /* Setup SDCC bus voter clock. */ + msm_host->bus_clk = devm_clk_get(&pdev->dev, "bus"); + if (!IS_ERR(msm_host->bus_clk)) { diff --git a/queue-5.15/mmc-sunxi-mmc-fix-dma-descriptors-allocated-above-32-bits.patch b/queue-5.15/mmc-sunxi-mmc-fix-dma-descriptors-allocated-above-32-bits.patch new file mode 100644 index 00000000000..72abd4dc466 --- /dev/null +++ b/queue-5.15/mmc-sunxi-mmc-fix-dma-descriptors-allocated-above-32-bits.patch @@ -0,0 +1,40 @@ +From e9f3fb523dbf476dc86beea23f5b5ca8f9687c93 Mon Sep 17 00:00:00 2001 +From: Samuel Holland +Date: Sun, 24 Apr 2022 18:17:50 -0500 +Subject: mmc: sunxi-mmc: Fix DMA descriptors allocated above 32 bits + +From: Samuel Holland + +commit e9f3fb523dbf476dc86beea23f5b5ca8f9687c93 upstream. + +Newer variants of the MMC controller support a 34-bit physical address +space by using word addresses instead of byte addresses. However, the +code truncates the DMA descriptor address to 32 bits before applying the +shift. This breaks DMA for descriptors allocated above the 32-bit limit. + +Fixes: 3536b82e5853 ("mmc: sunxi: add support for A100 mmc controller") +Signed-off-by: Samuel Holland +Reviewed-by: Andre Przywara +Reviewed-by: Jernej Skrabec +Cc: stable@vger.kernel.org +Link: https://lore.kernel.org/r/20220424231751.32053-1-samuel@sholland.org +Signed-off-by: Ulf Hansson +Signed-off-by: Greg Kroah-Hartman +--- + drivers/mmc/host/sunxi-mmc.c | 5 +++-- + 1 file changed, 3 insertions(+), 2 deletions(-) + +--- a/drivers/mmc/host/sunxi-mmc.c ++++ b/drivers/mmc/host/sunxi-mmc.c +@@ -377,8 +377,9 @@ static void sunxi_mmc_init_idma_des(stru + pdes[i].buf_addr_ptr1 = + cpu_to_le32(sg_dma_address(&data->sg[i]) >> + host->cfg->idma_des_shift); +- pdes[i].buf_addr_ptr2 = cpu_to_le32((u32)next_desc >> +- host->cfg->idma_des_shift); ++ pdes[i].buf_addr_ptr2 = ++ cpu_to_le32(next_desc >> ++ host->cfg->idma_des_shift); + } + + pdes[0].config |= cpu_to_le32(SDXC_IDMAC_DES0_FD); diff --git a/queue-5.15/net-stmmac-disable-split-header-sph-for-intel-platforms.patch b/queue-5.15/net-stmmac-disable-split-header-sph-for-intel-platforms.patch new file mode 100644 index 00000000000..bcd68de01fc --- /dev/null +++ b/queue-5.15/net-stmmac-disable-split-header-sph-for-intel-platforms.patch @@ -0,0 +1,65 @@ +From 47f753c1108e287edb3e27fad8a7511a9d55578e Mon Sep 17 00:00:00 2001 +From: Tan Tee Min +Date: Fri, 29 Apr 2022 19:58:07 +0800 +Subject: net: stmmac: disable Split Header (SPH) for Intel platforms + +From: Tan Tee Min + +commit 47f753c1108e287edb3e27fad8a7511a9d55578e upstream. + +Based on DesignWare Ethernet QoS datasheet, we are seeing the limitation +of Split Header (SPH) feature is not supported for Ipv4 fragmented packet. +This SPH limitation will cause ping failure when the packets size exceed +the MTU size. For example, the issue happens once the basic ping packet +size is larger than the configured MTU size and the data is lost inside +the fragmented packet, replaced by zeros/corrupted values, and leads to +ping fail. + +So, disable the Split Header for Intel platforms. + +v2: Add fixes tag in commit message. + +Fixes: 67afd6d1cfdf("net: stmmac: Add Split Header support and enable it in XGMAC cores") +Cc: # 5.10.x +Suggested-by: Ong, Boon Leong +Signed-off-by: Mohammad Athari Bin Ismail +Signed-off-by: Wong Vee Khee +Signed-off-by: Tan Tee Min +Signed-off-by: David S. Miller +Signed-off-by: Greg Kroah-Hartman +--- + drivers/net/ethernet/stmicro/stmmac/dwmac-intel.c | 1 + + drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 2 +- + include/linux/stmmac.h | 1 + + 3 files changed, 3 insertions(+), 1 deletion(-) + +--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-intel.c ++++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-intel.c +@@ -454,6 +454,7 @@ static int intel_mgbe_common_data(struct + plat->has_gmac4 = 1; + plat->force_sf_dma_mode = 0; + plat->tso_en = 1; ++ plat->sph_disable = 1; + + /* Multiplying factor to the clk_eee_i clock time + * period to make it closer to 100 ns. This value +--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c ++++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c +@@ -7081,7 +7081,7 @@ int stmmac_dvr_probe(struct device *devi + dev_info(priv->device, "TSO feature enabled\n"); + } + +- if (priv->dma_cap.sphen) { ++ if (priv->dma_cap.sphen && !priv->plat->sph_disable) { + ndev->hw_features |= NETIF_F_GRO; + priv->sph_cap = true; + priv->sph = priv->sph_cap; +--- a/include/linux/stmmac.h ++++ b/include/linux/stmmac.h +@@ -269,5 +269,6 @@ struct plat_stmmacenet_data { + int msi_rx_base_vec; + int msi_tx_base_vec; + bool use_phy_wol; ++ bool sph_disable; + }; + #endif diff --git a/queue-5.15/revert-sunrpc-attempt-af_local-connect-on-setup.patch b/queue-5.15/revert-sunrpc-attempt-af_local-connect-on-setup.patch new file mode 100644 index 00000000000..1966ed3b6a2 --- /dev/null +++ b/queue-5.15/revert-sunrpc-attempt-af_local-connect-on-setup.patch @@ -0,0 +1,36 @@ +From a3d0562d4dc039bca39445e1cddde7951662e17d Mon Sep 17 00:00:00 2001 +From: Trond Myklebust +Date: Fri, 29 Apr 2022 12:27:30 -0400 +Subject: Revert "SUNRPC: attempt AF_LOCAL connect on setup" + +From: Trond Myklebust + +commit a3d0562d4dc039bca39445e1cddde7951662e17d upstream. + +This reverts commit 7073ea8799a8cf73db60270986f14e4aae20fa80. + +We must not try to connect the socket while the transport is under +construction, because the mechanisms to safely tear it down are not in +place. As the code stands, we end up leaking the sockets on a connection +error. + +Reported-by: wanghai (M) +Cc: stable@vger.kernel.org +Signed-off-by: Trond Myklebust +Signed-off-by: Greg Kroah-Hartman +--- + net/sunrpc/xprtsock.c | 3 --- + 1 file changed, 3 deletions(-) + +--- a/net/sunrpc/xprtsock.c ++++ b/net/sunrpc/xprtsock.c +@@ -2848,9 +2848,6 @@ static struct rpc_xprt *xs_setup_local(s + } + xprt_set_bound(xprt); + xs_format_peer_addresses(xprt, "local", RPCBIND_NETID_LOCAL); +- ret = ERR_PTR(xs_local_setup_socket(transport)); +- if (ret) +- goto out_err; + break; + default: + ret = ERR_PTR(-EAFNOSUPPORT); diff --git a/queue-5.15/risc-v-relocate-dtb-if-it-s-outside-memory-region.patch b/queue-5.15/risc-v-relocate-dtb-if-it-s-outside-memory-region.patch new file mode 100644 index 00000000000..bf204fd9e20 --- /dev/null +++ b/queue-5.15/risc-v-relocate-dtb-if-it-s-outside-memory-region.patch @@ -0,0 +1,59 @@ +From c6fe81191bd74f7e6ae9ce96a4837df9485f3ab8 Mon Sep 17 00:00:00 2001 +From: Nick Kossifidis +Date: Tue, 22 Mar 2022 15:28:39 +0200 +Subject: RISC-V: relocate DTB if it's outside memory region + +From: Nick Kossifidis + +commit c6fe81191bd74f7e6ae9ce96a4837df9485f3ab8 upstream. + +In case the DTB provided by the bootloader/BootROM is before the kernel +image or outside /memory, we won't be able to access it through the +linear mapping, and get a segfault on setup_arch(). Currently OpenSBI +relocates DTB but that's not always the case (e.g. if FW_JUMP_FDT_ADDR +is not specified), and it's also not the most portable approach since +the default FW_JUMP_FDT_ADDR of the generic platform relocates the DTB +at a specific offset that may not be available. To avoid this situation +copy DTB so that it's visible through the linear mapping. + +Signed-off-by: Nick Kossifidis +Link: https://lore.kernel.org/r/20220322132839.3653682-1-mick@ics.forth.gr +Tested-by: Conor Dooley +Fixes: f105aa940e78 ("riscv: add BUILTIN_DTB support for MMU-enabled targets") +Cc: stable@vger.kernel.org +Signed-off-by: Palmer Dabbelt +Signed-off-by: Greg Kroah-Hartman +--- + arch/riscv/mm/init.c | 21 +++++++++++++++++++-- + 1 file changed, 19 insertions(+), 2 deletions(-) + +--- a/arch/riscv/mm/init.c ++++ b/arch/riscv/mm/init.c +@@ -218,8 +218,25 @@ static void __init setup_bootmem(void) + * early_init_fdt_reserve_self() since __pa() does + * not work for DTB pointers that are fixmap addresses + */ +- if (!IS_ENABLED(CONFIG_BUILTIN_DTB)) +- memblock_reserve(dtb_early_pa, fdt_totalsize(dtb_early_va)); ++ if (!IS_ENABLED(CONFIG_BUILTIN_DTB)) { ++ /* ++ * In case the DTB is not located in a memory region we won't ++ * be able to locate it later on via the linear mapping and ++ * get a segfault when accessing it via __va(dtb_early_pa). ++ * To avoid this situation copy DTB to a memory region. ++ * Note that memblock_phys_alloc will also reserve DTB region. ++ */ ++ if (!memblock_is_memory(dtb_early_pa)) { ++ size_t fdt_size = fdt_totalsize(dtb_early_va); ++ phys_addr_t new_dtb_early_pa = memblock_phys_alloc(fdt_size, PAGE_SIZE); ++ void *new_dtb_early_va = early_memremap(new_dtb_early_pa, fdt_size); ++ ++ memcpy(new_dtb_early_va, dtb_early_va, fdt_size); ++ early_memunmap(new_dtb_early_va, fdt_size); ++ _dtb_early_pa = new_dtb_early_pa; ++ } else ++ memblock_reserve(dtb_early_pa, fdt_totalsize(dtb_early_va)); ++ } + + early_init_fdt_scan_reserved_mem(); + dma_contiguous_reserve(dma32_phys_limit); diff --git a/queue-5.15/series b/queue-5.15/series index 56c6b832540..479a73c27c1 100644 --- a/queue-5.15/series +++ b/queue-5.15/series @@ -3,3 +3,20 @@ revert-parisc-fix-patch-code-locking-and-flushing.patch parisc-merge-model-and-model-name-into-one-line-in-proc-cpuinfo.patch alsa-hda-realtek-add-quirk-for-yoga-duet-7-13itl6-speakers.patch alsa-fireworks-fix-wrong-return-count-shorter-than-expected-by-4-bytes.patch +mmc-sdhci-msm-reset-gcc_sdcc_bcr-register-for-sdhc.patch +mmc-sunxi-mmc-fix-dma-descriptors-allocated-above-32-bits.patch +mmc-core-set-hs-clock-speed-before-sending-hs-cmd13.patch +gpiolib-of-fix-bounds-check-for-gpio-reserved-ranges.patch +x86-fpu-prevent-fpu-state-corruption.patch +kvm-x86-svm-account-for-family-17h-event-renumberings-in-amd_pmc_perf_hw_id.patch +iommu-vt-d-calculate-mask-for-non-aligned-flushes.patch +iommu-arm-smmu-v3-fix-size-calculation-in-arm_smmu_mm_invalidate_range.patch +drm-amd-display-avoid-reading-audio-pattern-past-audio_channels_count.patch +drm-amdgpu-do-not-use-passthrough-mode-in-xen-dom0.patch +risc-v-relocate-dtb-if-it-s-outside-memory-region.patch +revert-sunrpc-attempt-af_local-connect-on-setup.patch +timekeeping-mark-nmi-safe-time-accessors-as-notrace.patch +firewire-fix-potential-uaf-in-outbound_phy_packet_callback.patch +firewire-remove-check-of-list-iterator-against-head-past-the-loop-body.patch +firewire-core-extend-card-lock-in-fw_core_handle_bus_reset.patch +net-stmmac-disable-split-header-sph-for-intel-platforms.patch diff --git a/queue-5.15/timekeeping-mark-nmi-safe-time-accessors-as-notrace.patch b/queue-5.15/timekeeping-mark-nmi-safe-time-accessors-as-notrace.patch new file mode 100644 index 00000000000..93ca373d19c --- /dev/null +++ b/queue-5.15/timekeeping-mark-nmi-safe-time-accessors-as-notrace.patch @@ -0,0 +1,45 @@ +From 2c33d775ef4c25c0e1e1cc0fd5496d02f76bfa20 Mon Sep 17 00:00:00 2001 +From: Kurt Kanzenbach +Date: Thu, 28 Apr 2022 08:24:32 +0200 +Subject: timekeeping: Mark NMI safe time accessors as notrace + +From: Kurt Kanzenbach + +commit 2c33d775ef4c25c0e1e1cc0fd5496d02f76bfa20 upstream. + +Mark the CLOCK_MONOTONIC fast time accessors as notrace. These functions are +used in tracing to retrieve timestamps, so they should not recurse. + +Fixes: 4498e7467e9e ("time: Parametrize all tk_fast_mono users") +Fixes: f09cb9a1808e ("time: Introduce tk_fast_raw") +Reported-by: Steven Rostedt +Signed-off-by: Kurt Kanzenbach +Signed-off-by: Thomas Gleixner +Cc: stable@vger.kernel.org +Link: https://lore.kernel.org/r/20220426175338.3807ca4f@gandalf.local.home/ +Link: https://lore.kernel.org/r/20220428062432.61063-1-kurt@linutronix.de +Signed-off-by: Greg Kroah-Hartman +--- + kernel/time/timekeeping.c | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +--- a/kernel/time/timekeeping.c ++++ b/kernel/time/timekeeping.c +@@ -482,7 +482,7 @@ static __always_inline u64 __ktime_get_f + * of the following timestamps. Callers need to be aware of that and + * deal with it. + */ +-u64 ktime_get_mono_fast_ns(void) ++u64 notrace ktime_get_mono_fast_ns(void) + { + return __ktime_get_fast_ns(&tk_fast_mono); + } +@@ -494,7 +494,7 @@ EXPORT_SYMBOL_GPL(ktime_get_mono_fast_ns + * Contrary to ktime_get_mono_fast_ns() this is always correct because the + * conversion factor is not affected by NTP/PTP correction. + */ +-u64 ktime_get_raw_fast_ns(void) ++u64 notrace ktime_get_raw_fast_ns(void) + { + return __ktime_get_fast_ns(&tk_fast_raw); + } diff --git a/queue-5.15/x86-fpu-prevent-fpu-state-corruption.patch b/queue-5.15/x86-fpu-prevent-fpu-state-corruption.patch new file mode 100644 index 00000000000..076621f0adc --- /dev/null +++ b/queue-5.15/x86-fpu-prevent-fpu-state-corruption.patch @@ -0,0 +1,140 @@ +From 59f5ede3bc0f00eb856425f636dab0c10feb06d8 Mon Sep 17 00:00:00 2001 +From: Thomas Gleixner +Date: Sun, 1 May 2022 21:31:43 +0200 +Subject: x86/fpu: Prevent FPU state corruption + +From: Thomas Gleixner + +commit 59f5ede3bc0f00eb856425f636dab0c10feb06d8 upstream. + +The FPU usage related to task FPU management is either protected by +disabling interrupts (switch_to, return to user) or via fpregs_lock() which +is a wrapper around local_bh_disable(). When kernel code wants to use the +FPU then it has to check whether it is possible by calling irq_fpu_usable(). + +But the condition in irq_fpu_usable() is wrong. It allows FPU to be used +when: + + !in_interrupt() || interrupted_user_mode() || interrupted_kernel_fpu_idle() + +The latter is checking whether some other context already uses FPU in the +kernel, but if that's not the case then it allows FPU to be used +unconditionally even if the calling context interrupted a fpregs_lock() +critical region. If that happens then the FPU state of the interrupted +context becomes corrupted. + +Allow in kernel FPU usage only when no other context has in kernel FPU +usage and either the calling context is not hard interrupt context or the +hard interrupt did not interrupt a local bottomhalf disabled region. + +It's hard to find a proper Fixes tag as the condition was broken in one way +or the other for a very long time and the eager/lazy FPU changes caused a +lot of churn. Picked something remotely connected from the history. + +This survived undetected for quite some time as FPU usage in interrupt +context is rare, but the recent changes to the random code unearthed it at +least on a kernel which had FPU debugging enabled. There is probably a +higher rate of silent corruption as not all issues can be detected by the +FPU debugging code. This will be addressed in a subsequent change. + +Fixes: 5d2bd7009f30 ("x86, fpu: decouple non-lazy/eager fpu restore from xsave") +Reported-by: Filipe Manana +Signed-off-by: Thomas Gleixner +Tested-by: Filipe Manana +Reviewed-by: Borislav Petkov +Cc: stable@vger.kernel.org +Link: https://lore.kernel.org/r/20220501193102.588689270@linutronix.de +Signed-off-by: Greg Kroah-Hartman +--- + arch/x86/kernel/fpu/core.c | 67 +++++++++++++++++---------------------------- + 1 file changed, 26 insertions(+), 41 deletions(-) + +--- a/arch/x86/kernel/fpu/core.c ++++ b/arch/x86/kernel/fpu/core.c +@@ -25,17 +25,7 @@ + */ + union fpregs_state init_fpstate __ro_after_init; + +-/* +- * Track whether the kernel is using the FPU state +- * currently. +- * +- * This flag is used: +- * +- * - by IRQ context code to potentially use the FPU +- * if it's unused. +- * +- * - to debug kernel_fpu_begin()/end() correctness +- */ ++/* Track in-kernel FPU usage */ + static DEFINE_PER_CPU(bool, in_kernel_fpu); + + /* +@@ -43,42 +33,37 @@ static DEFINE_PER_CPU(bool, in_kernel_fp + */ + DEFINE_PER_CPU(struct fpu *, fpu_fpregs_owner_ctx); + +-static bool kernel_fpu_disabled(void) +-{ +- return this_cpu_read(in_kernel_fpu); +-} +- +-static bool interrupted_kernel_fpu_idle(void) +-{ +- return !kernel_fpu_disabled(); +-} +- +-/* +- * Were we in user mode (or vm86 mode) when we were +- * interrupted? +- * +- * Doing kernel_fpu_begin/end() is ok if we are running +- * in an interrupt context from user mode - we'll just +- * save the FPU state as required. +- */ +-static bool interrupted_user_mode(void) +-{ +- struct pt_regs *regs = get_irq_regs(); +- return regs && user_mode(regs); +-} +- + /* + * Can we use the FPU in kernel mode with the + * whole "kernel_fpu_begin/end()" sequence? +- * +- * It's always ok in process context (ie "not interrupt") +- * but it is sometimes ok even from an irq. + */ + bool irq_fpu_usable(void) + { +- return !in_interrupt() || +- interrupted_user_mode() || +- interrupted_kernel_fpu_idle(); ++ if (WARN_ON_ONCE(in_nmi())) ++ return false; ++ ++ /* In kernel FPU usage already active? */ ++ if (this_cpu_read(in_kernel_fpu)) ++ return false; ++ ++ /* ++ * When not in NMI or hard interrupt context, FPU can be used in: ++ * ++ * - Task context except from within fpregs_lock()'ed critical ++ * regions. ++ * ++ * - Soft interrupt processing context which cannot happen ++ * while in a fpregs_lock()'ed critical region. ++ */ ++ if (!in_hardirq()) ++ return true; ++ ++ /* ++ * In hard interrupt context it's safe when soft interrupts ++ * are enabled, which means the interrupt did not hit in ++ * a fpregs_lock()'ed critical region. ++ */ ++ return !softirq_count(); + } + EXPORT_SYMBOL(irq_fpu_usable); +