From: Greg Kroah-Hartman Date: Mon, 12 May 2025 09:39:08 +0000 (+0200) Subject: 6.1-stable patches X-Git-Tag: v5.15.183~55 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=8adc29bfb96ed53e666e081b416d02378e495a5f;p=thirdparty%2Fkernel%2Fstable-queue.git 6.1-stable patches added patches: drm-amd-display-shift-dmub-aux-reply-command-if-necessary.patch x86-mm-eliminate-window-where-tlb-flushes-may-be-inadvertently-skipped.patch --- diff --git a/queue-6.1/drm-amd-display-shift-dmub-aux-reply-command-if-necessary.patch b/queue-6.1/drm-amd-display-shift-dmub-aux-reply-command-if-necessary.patch new file mode 100644 index 0000000000..10f0b46704 --- /dev/null +++ b/queue-6.1/drm-amd-display-shift-dmub-aux-reply-command-if-necessary.patch @@ -0,0 +1,47 @@ +From 5a3846648c0523fd850b7f0aec78c0139453ab8b Mon Sep 17 00:00:00 2001 +From: Wayne Lin +Date: Fri, 18 Apr 2025 16:31:59 +0800 +Subject: drm/amd/display: Shift DMUB AUX reply command if necessary + +From: Wayne Lin + +commit 5a3846648c0523fd850b7f0aec78c0139453ab8b upstream. + +[Why] +Defined value of dmub AUX reply command field get updated but didn't +adjust dm receiving side accordingly. + +[How] +Check the received reply command value to see if it's updated version +or not. Adjust it if necessary. + +Fixes: ead08b95fa50 ("drm/amd/display: Fix race condition in DPIA AUX transfer") +Cc: Mario Limonciello +Cc: Alex Deucher +Reviewed-by: Ray Wu +Signed-off-by: Wayne Lin +Signed-off-by: Ray Wu +Tested-by: Daniel Wheeler +Signed-off-by: Alex Deucher +(cherry picked from commit d5c9ade755a9afa210840708a12a8f44c0d532f4) +Cc: stable@vger.kernel.org +Signed-off-by: Greg Kroah-Hartman +--- + drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 5 ++++- + 1 file changed, 4 insertions(+), 1 deletion(-) + +--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c ++++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c +@@ -10702,8 +10702,11 @@ int amdgpu_dm_process_dmub_aux_transfer_ + goto out; + } + ++ payload->reply[0] = adev->dm.dmub_notify->aux_reply.command & 0xF; ++ if (adev->dm.dmub_notify->aux_reply.command & 0xF0) ++ /* The reply is stored in the top nibble of the command. */ ++ payload->reply[0] = (adev->dm.dmub_notify->aux_reply.command >> 4) & 0xF; + +- payload->reply[0] = adev->dm.dmub_notify->aux_reply.command; + if (!payload->write && p_notify->aux_reply.length && + (payload->reply[0] == AUX_TRANSACTION_REPLY_AUX_ACK)) { + diff --git a/queue-6.1/series b/queue-6.1/series index 49d7af2d66..5aa4a6cdef 100644 --- a/queue-6.1/series +++ b/queue-6.1/series @@ -29,3 +29,5 @@ input-synaptics-enable-intertouch-on-tuxedo-infinitybook-pro-14-v5.patch staging-iio-adc-ad7816-correct-conditional-logic-for-store-mode.patch staging-axis-fifo-remove-hardware-resets-for-user-errors.patch staging-axis-fifo-correct-handling-of-tx_fifo_depth-for-size-validation.patch +x86-mm-eliminate-window-where-tlb-flushes-may-be-inadvertently-skipped.patch +drm-amd-display-shift-dmub-aux-reply-command-if-necessary.patch diff --git a/queue-6.1/x86-mm-eliminate-window-where-tlb-flushes-may-be-inadvertently-skipped.patch b/queue-6.1/x86-mm-eliminate-window-where-tlb-flushes-may-be-inadvertently-skipped.patch new file mode 100644 index 0000000000..cbbe0af845 --- /dev/null +++ b/queue-6.1/x86-mm-eliminate-window-where-tlb-flushes-may-be-inadvertently-skipped.patch @@ -0,0 +1,131 @@ +From fea4e317f9e7e1f449ce90dedc27a2d2a95bee5a Mon Sep 17 00:00:00 2001 +From: Dave Hansen +Date: Thu, 8 May 2025 15:41:32 -0700 +Subject: x86/mm: Eliminate window where TLB flushes may be inadvertently skipped + +From: Dave Hansen + +commit fea4e317f9e7e1f449ce90dedc27a2d2a95bee5a upstream. + +tl;dr: There is a window in the mm switching code where the new CR3 is +set and the CPU should be getting TLB flushes for the new mm. But +should_flush_tlb() has a bug and suppresses the flush. Fix it by +widening the window where should_flush_tlb() sends an IPI. + +Long Version: + +=== History === + +There were a few things leading up to this. + +First, updating mm_cpumask() was observed to be too expensive, so it was +made lazier. But being lazy caused too many unnecessary IPIs to CPUs +due to the now-lazy mm_cpumask(). So code was added to cull +mm_cpumask() periodically[2]. But that culling was a bit too aggressive +and skipped sending TLB flushes to CPUs that need them. So here we are +again. + +=== Problem === + +The too-aggressive code in should_flush_tlb() strikes in this window: + + // Turn on IPIs for this CPU/mm combination, but only + // if should_flush_tlb() agrees: + cpumask_set_cpu(cpu, mm_cpumask(next)); + + next_tlb_gen = atomic64_read(&next->context.tlb_gen); + choose_new_asid(next, next_tlb_gen, &new_asid, &need_flush); + load_new_mm_cr3(need_flush); + // ^ After 'need_flush' is set to false, IPIs *MUST* + // be sent to this CPU and not be ignored. + + this_cpu_write(cpu_tlbstate.loaded_mm, next); + // ^ Not until this point does should_flush_tlb() + // become true! + +should_flush_tlb() will suppress TLB flushes between load_new_mm_cr3() +and writing to 'loaded_mm', which is a window where they should not be +suppressed. Whoops. + +=== Solution === + +Thankfully, the fuzzy "just about to write CR3" window is already marked +with loaded_mm==LOADED_MM_SWITCHING. Simply checking for that state in +should_flush_tlb() is sufficient to ensure that the CPU is targeted with +an IPI. + +This will cause more TLB flush IPIs. But the window is relatively small +and I do not expect this to cause any kind of measurable performance +impact. + +Update the comment where LOADED_MM_SWITCHING is written since it grew +yet another user. + +Peter Z also raised a concern that should_flush_tlb() might not observe +'loaded_mm' and 'is_lazy' in the same order that switch_mm_irqs_off() +writes them. Add a barrier to ensure that they are observed in the +order they are written. + +Signed-off-by: Dave Hansen +Acked-by: Rik van Riel +Link: https://lore.kernel.org/oe-lkp/202411282207.6bd28eae-lkp@intel.com/ [1] +Fixes: 6db2526c1d69 ("x86/mm/tlb: Only trim the mm_cpumask once a second") [2] +Reported-by: Stephen Dolan +Cc: stable@vger.kernel.org +Acked-by: Ingo Molnar +Acked-by: Peter Zijlstra (Intel) +Signed-off-by: Linus Torvalds +Signed-off-by: Greg Kroah-Hartman +--- + arch/x86/mm/tlb.c | 23 +++++++++++++++++++++-- + 1 file changed, 21 insertions(+), 2 deletions(-) + +--- a/arch/x86/mm/tlb.c ++++ b/arch/x86/mm/tlb.c +@@ -617,7 +617,11 @@ void switch_mm_irqs_off(struct mm_struct + + choose_new_asid(next, next_tlb_gen, &new_asid, &need_flush); + +- /* Let nmi_uaccess_okay() know that we're changing CR3. */ ++ /* ++ * Indicate that CR3 is about to change. nmi_uaccess_okay() ++ * and others are sensitive to the window where mm_cpumask(), ++ * CR3 and cpu_tlbstate.loaded_mm are not all in sync. ++ */ + this_cpu_write(cpu_tlbstate.loaded_mm, LOADED_MM_SWITCHING); + barrier(); + } +@@ -880,8 +884,16 @@ done: + + static bool should_flush_tlb(int cpu, void *data) + { ++ struct mm_struct *loaded_mm = per_cpu(cpu_tlbstate.loaded_mm, cpu); + struct flush_tlb_info *info = data; + ++ /* ++ * Order the 'loaded_mm' and 'is_lazy' against their ++ * write ordering in switch_mm_irqs_off(). Ensure ++ * 'is_lazy' is at least as new as 'loaded_mm'. ++ */ ++ smp_rmb(); ++ + /* Lazy TLB will get flushed at the next context switch. */ + if (per_cpu(cpu_tlbstate_shared.is_lazy, cpu)) + return false; +@@ -890,8 +902,15 @@ static bool should_flush_tlb(int cpu, vo + if (!info->mm) + return true; + ++ /* ++ * While switching, the remote CPU could have state from ++ * either the prev or next mm. Assume the worst and flush. ++ */ ++ if (loaded_mm == LOADED_MM_SWITCHING) ++ return true; ++ + /* The target mm is loaded, and the CPU is not lazy. */ +- if (per_cpu(cpu_tlbstate.loaded_mm, cpu) == info->mm) ++ if (loaded_mm == info->mm) + return true; + + /* In cpumask, but not the loaded mm? Periodically remove by flushing. */