From: Yazen Ghannam <yazen.ghannam@amd.com>
To: OptoCloud <git@optocloud.no>
Cc: Tony Luck <tony.luck@intel.com>, Borislav Petkov <bp@alien8.de>,
Thomas Gleixner <tglx@kernel.org>, Ingo Molnar <mingo@redhat.com>,
Dave Hansen <dave.hansen@linux.intel.com>,
"H. Peter Anvin" <hpa@zytor.com>,
"x86@kernel.org" <x86@kernel.org>,
"linux-edac@vger.kernel.org" <linux-edac@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 1/3] x86/mce: Reset MCA_SYND between bank scans
Date: Thu, 3 Sep 2026 16:28:52 -0400 [thread overview]
Message-ID: <20260903202852.GA145182@yaz-khff2.amd.com> (raw)
In-Reply-To: <6XMrR2i2tP3toFjOshJwvZ6agC3N8DSZi74aW-2DJwC5_rGPf1aT6nsZzd55MHD0nMwxx6x-NaFHU_OQaH0t8BdJcjWoBHkcAf-udzh5TKw=@optocloud.no>
On Sun, Aug 30, 2026 at 04:40:01AM +0000, OptoCloud wrote:
> machine_check_poll() and __mc_scan_banks() both reuse a single
> struct mce_hw_err while iterating over the MCA banks. The record is
> zeroed once before the loop; each iteration then resets only MISC
> and ADDR.
>
> On SMCA, mce_read_aux() writes SYND only when MCI_STATUS_SYNDV is
> set. Nothing clears it again, so a bank that does not set SYNDV
> inherits the SYND value read for the previous bank in the same
> scan, and that stale value is printed and handed to the decoders as
> if it belonged to the current error.
True, but harmless in practice. If SYNDV is not set, then decoders
should not consider the value of MCA_SYND. It doesn't matter if the
value is '0' or garbage.
>
> Reset SYND at the start of each iteration in both loops, alongside
> the existing MISC and ADDR resets.
>
> Found by code inspection; not reproduced on hardware.
>
> Fixes: db819d60f672 ("x86/mce: Add support for new MCA_SYND register")
> Cc: stable@vger.kernel.org
I don't agree that this needs to go to the stable branches, since it's
not fixing a practical bug.
> Signed-off-by: Eirik Bøe <git@optocloud.no>
Overall, I think this is a fair patch. It does bring the MCA_SYND
behavior inline with the other registers.
Besides the minor nits above this looks good to me.
Reviewed-by: Yazen Ghannam <yazen.ghannam@amd.com>
Thanks,
Yazen
prev parent reply other threads:[~2026-09-03 20:29 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-30 4:40 [PATCH 1/3] x86/mce: Reset MCA_SYND between bank scans OptoCloud
2026-09-03 20:28 ` Yazen Ghannam [this message]
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=20260903202852.GA145182@yaz-khff2.amd.com \
--to=yazen.ghannam@amd.com \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=git@optocloud.no \
--cc=hpa@zytor.com \
--cc=linux-edac@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=tglx@kernel.org \
--cc=tony.luck@intel.com \
--cc=x86@kernel.org \
/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.