Patch "x86/nmi: Fix the inverse "in NMI handler" check" has been added to the 6.7-stable tree

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



This is a note to let you know that I've just added the patch titled

    x86/nmi: Fix the inverse "in NMI handler" check

to the 6.7-stable tree which can be found at:
    http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary

The filename of the patch is:
     x86-nmi-fix-the-inverse-in-nmi-handler-check.patch
and it can be found in the queue-6.7 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@xxxxxxxxxxxxxxx> know about it.



commit 4cbeb01b77b347f6441611fc77ca15f3de457b25
Author: Breno Leitao <leitao@xxxxxxxxxx>
Date:   Wed Feb 7 08:52:35 2024 -0800

    x86/nmi: Fix the inverse "in NMI handler" check
    
    [ Upstream commit d54e56f31a34fa38fcb5e91df609f9633419a79a ]
    
    Commit 344da544f177 ("x86/nmi: Print reasons why backtrace NMIs are
    ignored") creates a super nice framework to diagnose NMIs.
    
    Every time nmi_exc() is called, it increments a per_cpu counter
    (nsp->idt_nmi_seq). At its exit, it also increments the same counter.  By
    reading this counter it can be seen how many times that function was called
    (dividing by 2), and, if the function is still being executed, by checking
    the idt_nmi_seq's least significant bit.
    
    On the check side (nmi_backtrace_stall_check()), that variable is queried
    to check if the NMI is still being executed, but, there is a mistake in the
    bitwise operation. That code wants to check if the least significant bit of
    the idt_nmi_seq is set or not, but does the opposite, and checks for all
    the other bits, which will always be true after the first exc_nmi()
    executed successfully.
    
    This appends the misleading string to the dump "(CPU currently in NMI
    handler function)"
    
    Fix it by checking the least significant bit, and if it is set, append the
    string.
    
    Fixes: 344da544f177 ("x86/nmi: Print reasons why backtrace NMIs are ignored")
    Signed-off-by: Breno Leitao <leitao@xxxxxxxxxx>
    Signed-off-by: Thomas Gleixner <tglx@xxxxxxxxxxxxx>
    Reviewed-by: Paul E. McKenney <paulmck@xxxxxxxxxx>
    Cc: stable@xxxxxxxxxxxxxxx
    Link: https://lore.kernel.org/r/20240207165237.1048837-1-leitao@xxxxxxxxxx
    Signed-off-by: Sasha Levin <sashal@xxxxxxxxxx>

diff --git a/arch/x86/kernel/nmi.c b/arch/x86/kernel/nmi.c
index 3082cf24b69e3..6da2cfa23c293 100644
--- a/arch/x86/kernel/nmi.c
+++ b/arch/x86/kernel/nmi.c
@@ -636,7 +636,7 @@ void nmi_backtrace_stall_check(const struct cpumask *btp)
 			msgp = nmi_check_stall_msg[idx];
 			if (nsp->idt_ignored_snap != READ_ONCE(nsp->idt_ignored) && (idx & 0x1))
 				modp = ", but OK because ignore_nmis was set";
-			if (nmi_seq & ~0x1)
+			if (nmi_seq & 0x1)
 				msghp = " (CPU currently in NMI handler function)";
 			else if (nsp->idt_nmi_seq_snap + 1 == nmi_seq)
 				msghp = " (CPU exited one NMI handler function)";




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux