RFC GHES NMI handler cleanup
Get series with b4
b4 am [email protected]Versions newest first
- v1 RFC Latest5 patches 26 repliesIn review
Patches in v1 No applies recorded yet
| # | Subject and files | Size | Replies | Applied |
|---|---|---|---|---|
| 1/5 | GHES: Carve out error queueing in a separate functiondrivers/ | +29 | 0 replies | |
| 2/5 | GHES: Carve out the panic functionalitydrivers/ | +14 | 0 replies | |
| 3/5 | GHES: Panic right after detectiondrivers/ | +6 | 0 replies | |
| 4/5 | GHES: Elliminate double-loop in the NMI handlerdrivers/ | +2 | 0 replies | |
| 5/5 | GHES: Make NMI handler have a single readerdrivers/ | +7 | 26 replies |
Reviews trailers per patch
No Reviewed-by, Acked-by or Tested-by trailers for v1 yet.
Cover letter [RFC PATCH 0/5] GHES NMI handler cleanup
From: Borislav Petkov <[email protected]>
So this patchset is the result of us seeing this while debugging a customer issue:
[ 118.113136] INFO: NMI handler (ghes_notify_nmi) took too long to run: 1.005 msecs
Looking at that NMI handler, it could use a good scrubbing as it has grown some needless fat. So let's try it.
First 4 patches simplify it and clean it, and the last one does the bold move of making the status reader CPU be a single one based on the not-100-percent-confirmed observation that GHES error sources are global in the firmware glue and thus only one reader suffices to see all errors.
This last thing still needs to be confirmed but I'm sending the patches now so that people can look at them and poke holes. Thus the RFC tag.
Thanks.
Borislav Petkov (4):
GHES: Carve out error queueing in a separate function
GHES: Carve out the panic functionality
GHES: Panic right after detection
GHES: Elliminate double-loop in the NMI handler
Jiri Kosina (1):
GHES: Make NMI handler have a single reader
drivers/acpi/apei/ghes.c | 108 ++++++++++++++++++++++++----------------------- 1 file changed, 55 insertions(+), 53 deletions(-)
Signature · 1 line
2.3.3