[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20260210150117.GBaYtIPfsP0Txw7iIc@fat_crate.local>
Date: Tue, 10 Feb 2026 16:01:17 +0100
From: Borislav Petkov <bp@...en8.de>
To: "Luck, Tony" <tony.luck@...el.com>
Cc: "Li, Rongqing" <lirongqing@...du.com>,
Nikolay Borisov <nik.borisov@...e.com>,
Thomas Gleixner <tglx@...nel.org>, Ingo Molnar <mingo@...hat.com>,
Dave Hansen <dave.hansen@...ux.intel.com>,
"x86@...nel.org" <x86@...nel.org>,
"H . Peter Anvin" <hpa@...or.com>,
Yazen Ghannam <yazen.ghannam@....com>,
"Zhuo, Qiuxu" <qiuxu.zhuo@...el.com>,
Avadhut Naik <avadhut.naik@....com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-edac@...r.kernel.org" <linux-edac@...r.kernel.org>
Subject: Re: [PATCH] x86/mce: Fix timer interval adjustment after logging a
MCE event
On Mon, Feb 09, 2026 at 09:37:35AM -0800, Luck, Tony wrote:
> If the system is now running in some mixed mode of polling and
> interrupts, then it is unclear what should be done in various
> new cases.
Well, what about CMCI? AMD has similar interrupt types. Those handlers end up
in the same path of machine_check_poll() and the above scenario can happen,
AFAICT.
> I don't think we care. If we miss out halving the interval becuause an
> error was logged between timer based polling, nothing really bad will
> happen. The interval might get sorted out on the next interval.
Right, that's what I'm thinking too.
> Unless someone has a real world case where something is going badly
> wrong, then I don't think any changes are needed to cover this race.
Ok, let's try the simple thing first.
Thx.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
Powered by blists - more mailing lists