From 3421ddbe6d64e55b76a67d57cef9e950b3d873ba Mon Sep 17 00:00:00 2001 From: Mark Brown Date: Mon, 24 Jul 2023 14:09:19 +0100 Subject: [PATCH 1/3] arm64/fpsimd: Don't flush SME register hardware state along with thread We recently changed the fpsimd thread flush to flush the physical SME state as well as the thread state for the current thread. Unfortunately this leads to intermittent corruption in interaction with the lazy FPSIMD register switching. When under heavy load such as can be triggered by the startup phase of fp-stress it is possible that the current thread may not be scheduled prior to returning to userspace, and indeed we may end up returning to the last thread that was scheduled on the PE without ever exiting the kernel to any other task. If that happens then we will not reload the register state from memory, leading to loss of any SME register state. Since this was purely an attempt to defensively close off potential problems revert the change. Fixes: af3215fd0230 ("arm64/fpsimd: Exit streaming mode when flushing tasks") Signed-off-by: Mark Brown Link: https://lore.kernel.org/r/20230724-arm64-dont-flush-smstate-v1-1-9a8b637ace6c@kernel.org Signed-off-by: Catalin Marinas --- arch/arm64/kernel/fpsimd.c | 1 - 1 file changed, 1 deletion(-) diff --git a/arch/arm64/kernel/fpsimd.c b/arch/arm64/kernel/fpsimd.c index 89d54a5242d1..9d7d10d60bfd 100644 --- a/arch/arm64/kernel/fpsimd.c +++ b/arch/arm64/kernel/fpsimd.c @@ -1666,7 +1666,6 @@ void fpsimd_flush_thread(void) fpsimd_flush_thread_vl(ARM64_VEC_SME); current->thread.svcr = 0; - sme_smstop(); } current->thread.fp_type = FP_STATE_FPSIMD; From 05d881b85b48c7ac6a7c92ce00aa916c4a84d052 Mon Sep 17 00:00:00 2001 From: Mark Brown Date: Wed, 26 Jul 2023 13:12:26 +0100 Subject: [PATCH 2/3] arm64/sme: Set new vector length before reallocating As part of fixing the allocation of the buffer for SVE state when changing SME vector length we introduced an immediate reallocation of the SVE state, this is also done when changing the SVE vector length for consistency. Unfortunately this reallocation is done prior to writing the new vector length to the task struct, meaning the allocation is done with the old vector length and can lead to memory corruption due to an undersized buffer being used. Move the update of the vector length before the allocation to ensure that the new vector length is taken into account. For some reason this isn't triggering any problems when running tests on the arm64 fixes branch (even after repeated tries) but is triggering issues very often after merge into mainline. Fixes: d4d5be94a878 ("arm64/fpsimd: Ensure SME storage is allocated after SVE VL changes") Signed-off-by: Mark Brown Cc: Link: https://lore.kernel.org/r/20230726-arm64-fix-sme-fix-v1-1-7752ec58af27@kernel.org Signed-off-by: Catalin Marinas --- arch/arm64/kernel/fpsimd.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm64/kernel/fpsimd.c b/arch/arm64/kernel/fpsimd.c index 9d7d10d60bfd..520b681a07bb 100644 --- a/arch/arm64/kernel/fpsimd.c +++ b/arch/arm64/kernel/fpsimd.c @@ -917,6 +917,8 @@ int vec_set_vector_length(struct task_struct *task, enum vec_type type, if (task == current) put_cpu_fpsimd_context(); + task_set_vl(task, type, vl); + /* * Free the changed states if they are not in use, SME will be * reallocated to the correct size on next use and we just @@ -931,8 +933,6 @@ int vec_set_vector_length(struct task_struct *task, enum vec_type type, if (free_sme) sme_free(task); - task_set_vl(task, type, vl); - out: update_tsk_thread_flag(task, vec_vl_inherit_flag(type), flags & PR_SVE_VL_INHERIT); From 003e6b56d780095a9adc23efc9cb4b4b4717169b Mon Sep 17 00:00:00 2001 From: Guanghui Feng Date: Mon, 17 Jul 2023 19:33:45 +0800 Subject: [PATCH 3/3] ACPI/IORT: Remove erroneous id_count check in iort_node_get_rmr_info() According to the ARM IORT specifications DEN 0049 issue E, the "Number of IDs" field in the ID mapping format reports the number of IDs in the mapping range minus one. In iort_node_get_rmr_info(), we erroneously skip ID mappings whose "Number of IDs" equal to 0, resulting in valid mapping nodes with a single ID to map being skipped, which is wrong. Fix iort_node_get_rmr_info() by removing the bogus id_count check. Fixes: 491cf4a6735a ("ACPI/IORT: Add support to retrieve IORT RMR reserved regions") Signed-off-by: Guanghui Feng Cc: # 6.0.x Acked-by: Lorenzo Pieralisi Tested-by: Hanjun Guo Link: https://lore.kernel.org/r/1689593625-45213-1-git-send-email-guanghuifeng@linux.alibaba.com Signed-off-by: Catalin Marinas --- drivers/acpi/arm64/iort.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c index 3631230a61c8..56d887323ae5 100644 --- a/drivers/acpi/arm64/iort.c +++ b/drivers/acpi/arm64/iort.c @@ -1007,9 +1007,6 @@ static void iort_node_get_rmr_info(struct acpi_iort_node *node, for (i = 0; i < node->mapping_count; i++, map++) { struct acpi_iort_node *parent; - if (!map->id_count) - continue; - parent = ACPI_ADD_PTR(struct acpi_iort_node, iort_table, map->output_reference); if (parent != iommu)