Re: Hardware Error Kernel Mini-Summit

From: Ingo Molnar
Date: Tue May 18 2010 - 15:35:23 EST

* Borislav Petkov <bp@xxxxxxxxx> wrote:

> Well, we have a trace_mce_record tracepoint in the
> mcheck code which calls all the necessary callbacks when
> an mcheck occurs. For the time being, the idea is to use
> the mce.c ring buffer for early mchecks and copy them to
> the regular ftrace per-cpu buffer after the last has
> been initialized. Later, we could switch to a another
> early bootmem buffer if there's need to.

The end result would be even simpler by one more step:
with persistent events we just use them and dont need the
mce.c ringbuffer at all. (getting rid of that complication
is one of the code cleanliness benefits i see in this move
as a x86 maintainer - beyond the obvious generalization
and unification benefits.)

> Also, we want to have a userspace daemon that reads out
> the mces from the trace buffer and does further
> processing like thresholding etc in userspace.
> Concerning critical errors, there we bypass the perf
> subsystem and execute the smallest amount of code
> possible while trying to shutdown gracefully if the
> error type allows that.

Yeah. Each perf_event can have arbitrary callbacks with
add-on (or critical) functionality. We would activate the
event(s) during bootup and it would do its thing from that
point on: critical functionality gets a direct path via
the callback, and every other event that survives goes via
the regular perf output channels, to one (or more)
consumers/subscribers of these events.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at