[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ae870a38-e7ee-4334-ba4d-ca3e4e17a53d@zytor.com>
Date: Wed, 29 May 2024 14:12:19 -0700
From: "H. Peter Anvin" <hpa@...or.com>
To: Jacob Pan <jacob.jun.pan@...ux.intel.com>, X86 Kernel <x86@...nel.org>,
LKML <linux-kernel@...r.kernel.org>,
Thomas Gleixner <tglx@...utronix.de>,
Dave Hansen <dave.hansen@...el.com>, Ingo Molnar <mingo@...hat.com>,
Borislav Petkov <bp@...en8.de>, linux-perf-users@...r.kernel.org,
Peter Zijlstra <peterz@...radead.org>
Cc: Andi Kleen <andi.kleen@...el.com>, Xin Li <xin3.li@...el.com>
Subject: Re: [PATCH 4/6] x86/irq: Process nmi sources in NMI handler
On 5/29/24 13:33, Jacob Pan wrote:
> +
> + rcu_read_lock();
> + /* Bit 0 is for unknown NMI sources, skip it. */
> + for_each_set_bit_from(vec, &source_bitmask, NR_NMI_SOURCE_VECTORS) {
> + a = rcu_dereference(nmiaction_src_table[vec]);
> + if (!a) {
> + pr_warn_ratelimited("NMI received %d no handler", vec);
> + continue;
> + }
In this case, you should assume some chipset hardware or VMM is giving
you garbage in the event bitmask, and treat it as if bit 0 were set.
-hpa
Powered by blists - more mailing lists