Some Intel CPUs implement a "bitfix filter" to suppress reporting of the
same corrected errors repeatedly in the case where aging silicon
develops stuck bits.

But when systems run for weeks, or months, the filters may become clogged
with transient errors.

When the filter is full (indicated by a "yellow" signature in a machine
check bank) clear the filter. This may make space for additional hard
errors.

Save a time stamp when clearing a filter. Log with "WARN" severity if
the filter overflows quickly (in tem minutes or less).

This code was originally developend by Qiuxu as an add-on to an EDAC
driver. But not everyone wants to run an EDAC driver, so I pulled the
code out into a standalone platform driver. Much of Qiuxu's code was
cut-and-pasted into this driver, so he gets Co-developed-by credit
throughout.

Qiuxu Zhuo (1):
  cacheinfo: Export get_cpu_cacheinfo_id() for loadable modules

Tony Luck (6):
  x86/mce: Enumeration updates for Intel bitfix filter reset
  platform/x86/intel/bff: Add stub Intel bitfix filter driver
  platform/x86/intel/bff: Add Diamond Rapids support
  platform/x86/intel/bff: Reset bitfix filter when it overflows
  platform/x86/intel/bff: Compute unique ID for overflowed filter
  platform/x86/intel/bff: Report frequent filter resets

 include/linux/cacheinfo.h           |  12 +-
 arch/x86/include/asm/mce.h          |   6 +
 arch/x86/include/asm/msr-index.h    |   2 +
 drivers/base/cacheinfo.c            |  17 ++
 drivers/platform/x86/intel/bff.c    | 284 ++++++++++++++++++++++++++++
 drivers/platform/x86/intel/Kconfig  |  13 ++
 drivers/platform/x86/intel/Makefile |   1 +
 7 files changed, 324 insertions(+), 11 deletions(-)
 create mode 100644 drivers/platform/x86/intel/bff.c


base-commit: 8d3ae59288f1e7d58d76558a6ee96d533bc5019f
-- 
2.55.0

On Tue, Aug 25, 2026 at 11:15:19AM -0700, Tony Luck wrote:
> This code was originally developend by Qiuxu as an add-on to an EDAC
> driver. But not everyone wants to run an EDAC driver,

Interesting, what's so bad about EDAC drivers that makes you move all that
functionality which is clearly RAS/MCE/EDAC into some random platform driver?

There's also arch/x86/kernel/cpu/mce/intel.c and that doesn't fit either?

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

> > This code was originally developend by Qiuxu as an add-on to an EDAC
> > driver. But not everyone wants to run an EDAC driver,
>
> Interesting, what's so bad about EDAC drivers that makes you move all that
> functionality which is clearly RAS/MCE/EDAC into some random platform driver?

Mostly that not everyone wants to run EDAC drivers.

> There's also arch/x86/kernel/cpu/mce/intel.c and that doesn't fit either?

Plausibly. But it is model specific. Needs to know how h/w banks are shared
between logical CPUs so it can get the time comparisons right when a shared
bank reports BFF overflow on different CPUs. Intel doesn't have any enumeration
for bank sharing, and changes things often.

It's also just for one (not yet released) CPU model today. So, building it into the MCE
code would be overhead for almost everyone.

But I can move it if you think that is a better place for it.

-Tony

On Tue, Aug 25, 2026 at 06:55:27PM +0000, Luck, Tony wrote:
> Mostly that not everyone wants to run EDAC drivers.

Just because or is there a particular reason?

Because we could try to address those reasons if they were more concrete and
valid...

> Plausibly. But it is model specific. Needs to know how h/w banks are shared
> between logical CPUs so it can get the time comparisons right when a shared
> bank reports BFF overflow on different CPUs. Intel doesn't have any enumeration
> for bank sharing, and changes things often.
> 
> It's also just for one (not yet released) CPU model today. So, building it into the MCE
> code would be overhead for almost everyone.
>
> But I can move it if you think that is a better place for it.

Well, my angle is: we already have soo much RAS glue in the kernel so adding
a *platform* driver for it is simply unnecessary.

For example, drivers/edac/mce_amd.c is the whole AMD MCE decoding and even
though it is in drivers/edac/, it is not really an EDAC driver. So your BFFs
(wonderful acronym btw :-P) would likely fit there too.

And looking at the code, it looks very familiar to that thing - simply
a notifier callback with a bunch of logic to decode and report the error.

And there's drivers/ras/ too.

And we already have the whole machinery around it so let's move it somewhere
more fitting than in yet another new place pls.

Thx.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette