From: Jasjeet Rangi <jrangi@purestorage.com>
To: bp@alien8.de
Cc: Smita.KoralahalliChannabasappa@amd.com,
dave.hansen@linux.intel.com, dgiani@purestorage.com,
hpa@zytor.com, jrangi@purestorage.com,
linux-edac@vger.kernel.org, mingo@redhat.com,
msaggi@purestorage.com, rhan@purestorage.com,
rjethwani@purestorage.com, stable@vger.kernel.org,
tglx@kernel.org, tony.luck@intel.com, x86@kernel.org,
yazen.ghannam@amd.com
Subject: Re: [PATCH v2 1/2] x86/mce/amd: Fix inverted interrupt enablement during storm handling
Date: Wed, 19 Aug 2026 00:46:00 -0600 [thread overview]
Message-ID: <20260819064601.1972932-1-jrangi@purestorage.com> (raw)
In-Reply-To: <20260818190250.GAaoSsWiKOuj4gRYsl@fat_crate.local>
I'm ok with the queued patch because it still fixes an important bug
(disabling interrupts on storm end is not correct). The rest of this
reply is talking about the concern that storms are not handled
properly in the AMD driver. I can make that a new patch thread if we
agree to make the behavior more Intel like.
On Tue, Aug 18, 2026 at 12:03 PM Borislav Petkov <bp@alien8.de> wrote:
> On Mon, Aug 17, 2026 at 12:51:08PM -0600, Jasjeet Rangi wrote:
> > Inverting `on` in mce_amd_handle_storm() alone is not enough because
> > clear_bank() will immediately and unconditionally enable the interrupt
> > again.
>
> And?
>
> What would happen then?
>
> Did you read my previous reply?
On AMD a machine_check_poll() call will not necessarily set ErrCnt to 0.
In fact, it will not reset ErrCnt at all unless the overflow bit is
set. And the overflow bit gets set when it's time to generate an
interrupt. (Yazen and Smita please correct me if I'm wrong)
The threshold is not always high on AMD either. Since eeb3f76d73ba
(x86/mce: Save and use APEI corrected threshold limit)
it gets the value from the BIOS. The default on an AMD system I was
using was only 10. So ErrCnt will get reset to 4085 on that system
when the overflow bit is set. That is enough to not meaningfully
reduce the interrupt rate during an interrupt storm.
Unlike Intel, the AMD driver doesn't set the threshold to an extremely
large value when storm mode is turned on. It keeps it set to the same
configured value (default from BIOS).
So if interrupts are left enabled during storm mode like they would be
even with the queued patch, the AMD driver doesn't really reduce the
interrupt rate during a storm like the Intel driver does.
If we don't want to diverge from Intel, then the correct thing to do is
to update the AMD driver to do what the Intel driver does. I.e. don't
disable interrupts, but set the threshold_limit to a large value like
THRESHOLD_MAX during storm on, and restore it to what it was before upon
storm off.
> Yeah, we don't protect users from themselves, you know :)
I don't think having threshold=1 on AMD is too crazy. On the Intel
driver for example it defaults to 1 if not overridden by the BIOS.
```
/* Linux non-storm CMCI threshold (may be overridden by BIOS) */
#define CMCI_THRESHOLD 1
```
> We do clear MCi_MISC[ErrCnt] to 0 so that's the "highest' value we can do
> before we raise an interrupt there :)
And on AMD it does not get set to 0 after an interrupt. It gets set to
THRESHOLD_MAX - threshold_limit. So if your limit is 10, the ErrCnt will
get reset to 4085. This is the behavior since eeb3f76d73ba
(x86/mce: Save and use APEI corrected threshold limit). Prior to that
ErrCnt would get reset to 0 by default on AMD.
Thanks,
Jasjeet
next prev parent reply other threads:[~2026-08-19 6:47 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-12 22:15 [PATCH v2 0/2] x86/mce/amd: Fix inverted interrupt enablement during storm handling Jasjeet Rangi
2026-08-12 22:15 ` [PATCH v2 1/2] " Jasjeet Rangi
2026-08-14 23:24 ` Borislav Petkov
2026-08-17 18:51 ` Jasjeet Rangi
2026-08-18 19:02 ` Borislav Petkov
2026-08-19 6:46 ` Jasjeet Rangi [this message]
2026-08-19 14:06 ` Yazen Ghannam
2026-08-19 17:59 ` Jasjeet Rangi
2026-08-12 22:15 ` [PATCH v2 2/2] x86/mce: Rename MCE storm handler parameters for storm mode Jasjeet Rangi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260819064601.1972932-1-jrangi@purestorage.com \
--to=jrangi@purestorage.com \
--cc=Smita.KoralahalliChannabasappa@amd.com \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=dgiani@purestorage.com \
--cc=hpa@zytor.com \
--cc=linux-edac@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=msaggi@purestorage.com \
--cc=rhan@purestorage.com \
--cc=rjethwani@purestorage.com \
--cc=stable@vger.kernel.org \
--cc=tglx@kernel.org \
--cc=tony.luck@intel.com \
--cc=x86@kernel.org \
--cc=yazen.ghannam@amd.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.