All of lore.kernel.org
 help / color / mirror / Atom feed
* [GIT PULL for v6.10-rc6] edac fixes for kernel 6.11
@ 2024-06-26  9:33 Mauro Carvalho Chehab
  2024-06-26 10:02 ` Borislav Petkov
  0 siblings, 1 reply; 2+ messages in thread
From: Mauro Carvalho Chehab @ 2024-06-26  9:33 UTC (permalink / raw)
  To: Borislav Petkov
  Cc: Tony Luck, EDAC Mailing List, Linux Kernel Mailing List,
	Mauro Carvalho Chehab, Shengwei Luo, Daniel Ferguson, Jose,
	Jason Tian, Jonathan Cameron, Roberto Sassu

Hi Borislav,

Please pull from:
  git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-edac tags/edac/v6.10-1

For two patches that fix UEFI 2.6+ implementation of the ARM trace event, 
as the original implementation was incomplete.

The patches on this series was sent at:
	https://lore.kernel.org/all/20240321-b4-arm-ras-error-vendor-info-v5-rc3-v5-0-850f9bfb97a8@os.amperecomputing.com/

I did a couple of changes at the first patch addressing some coding style
issues. At the second patch, I replaced the original description to a proper
one identifying precisely why the patch is needed and what it does.

In summary:
changeset e9279e83ad1f ("trace, ras: add ARM processor error trace event")
was incomplete: it added a trace event that was reporting only some fields
of the CPER record generated for ARM processor from UEFI 2.6 spec.

Those are not enough to actually parse such events on userspace, nor to
take any actions like isolating problematic CPU cores.

The patch was validated with the help of an ARM EINJ code for QEMU:

	https://github.com/mchehab/rasdaemon/wiki/error-injection

I tested the ghes and cper reports both with and without this change,
using different versions of rasdaemon, with and without support for
the extended trace event. Those are a summary of the test results:

- adding more fields to the trace events didn't break userspace API:
  both versions of rasdaemon handled it;

- the rasdaemon patches to handle the new trace report was missing
  a backward-compatibility logic. I fixed already. With that, rasdaemon
  can handle both old and new trace events.

Btw, rasdaemon has gained support for the extended trace since its
version 0.5.8 (released in 2021). I didn't saw any issues there
complain about troubles on it, so either distros used on ARM servers
are using an old version of rasdaemon, or they're carrying on the trace
event changes as well.

Regards,
Mauro

---


The following changes since commit 1613e604df0cd359cf2a7fbd9be7a0bcfacfabd0:


Thanks,
Mauro

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: [GIT PULL for v6.10-rc6] edac fixes for kernel 6.11
  2024-06-26  9:33 [GIT PULL for v6.10-rc6] edac fixes for kernel 6.11 Mauro Carvalho Chehab
@ 2024-06-26 10:02 ` Borislav Petkov
  0 siblings, 0 replies; 2+ messages in thread
From: Borislav Petkov @ 2024-06-26 10:02 UTC (permalink / raw)
  To: Mauro Carvalho Chehab
  Cc: Tony Luck, EDAC Mailing List, Linux Kernel Mailing List,
	Mauro Carvalho Chehab, Shengwei Luo, Daniel Ferguson, Jose,
	Jason Tian, Jonathan Cameron, Roberto Sassu

On Wed, Jun 26, 2024 at 11:33:41AM +0200, Mauro Carvalho Chehab wrote:
> Hi Borislav,
> 
> Please pull from:
>   git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-edac tags/edac/v6.10-1

Do:

git tag -l <edac tree>

to see how we're naming the EDAC tags and use the same scheme pls.

> For two patches that fix UEFI 2.6+ implementation of the ARM trace event, 
> as the original implementation was incomplete.
> 
> The patches on this series was sent at:
> 	https://lore.kernel.org/all/20240321-b4-arm-ras-error-vendor-info-v5-rc3-v5-0-850f9bfb97a8@os.amperecomputing.com/

ac3a74c73a6c (tag: refs/tags/edac/v6.10-1) RAS: Report all ARM processor CPER information to userspace
54481ee6de96 RAS: ACPI: APEI: add conditional compilation to ARM specific error reporting routines.

This is an ACPI patch so it needs Rafael.

Then it needs a Link tag. The ordering we use in the EDAC tree is just like in
tip:

Fixes:
Closes:
Reported-by:
Suggested-by:
SOB chain
Reviewed-by:
Acked-by:
Tested-by:
CC:
Link:

Then, the ifdeffery is ugly but ghes_handle_arm_hw_error() at least puts it
inside the function. log_arm_hw_error() should do the same and then you don't
need the ifdeffery around the prototype.

Patch 1 needs massaging too.

So please send them as a normal set so that I can take a proper look first.

Thx.

-- 
Regards/Gruss,
    Boris.

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

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2024-06-26 10:02 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2024-06-26  9:33 [GIT PULL for v6.10-rc6] edac fixes for kernel 6.11 Mauro Carvalho Chehab
2024-06-26 10:02 ` Borislav Petkov

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.