diff options
author | Arjan van de Ven <arjan@linux.intel.com> | 2007-12-20 14:01:17 (GMT) |
---|---|---|
committer | Ingo Molnar <mingo@elte.hu> | 2007-12-20 14:01:17 (GMT) |
commit | 2c3b20e91fe3a083c5d9bc79437c485866ea251c (patch) | |
tree | 6d2b9e00efc89452863e71a8712398aeee3eccdd /net/nonet.c | |
parent | 67e2be02328b9a61a9c799fbdd4ec94d7da0c323 (diff) | |
download | linux-2c3b20e91fe3a083c5d9bc79437c485866ea251c.tar.xz |
debug: add end-of-oops marker
Right now it's nearly impossible for parsers that collect kernel crashes
from logs or emails (such as www.kerneloops.org) to detect the
end-of-oops condition. In addition, it's not currently possible to
detect whether or not 2 oopses that look alike are actually the same
oops reported twice, or are truly two unique oopses.
This patch adds an end-of-oops marker, and makes the end marker include
a very simple 64-bit random ID to be able to detect duplicate reports.
Normally, this ID is calculated as a late_initcall() (in the hope that
at that time there is enough entropy to get a unique enough ID); however
for early oopses the oops_exit() function needs to generate the ID on
the fly.
We do this all at the _end_ of an oops printout, so this does not impact
our ability to get the most important portions of a crash out to the
console first.
[ Sidenote: the already existing oopses-since-bootup counter we print
during crashes serves as the differentiator between multiple oopses
that trigger during the same bootup. ]
Tested on 32-bit and 64-bit x86. Artificially injected very early
crashes as well, as expected they result in this constant ID after
multiple bootups:
---[ end trace ca143223eefdc828 ]---
---[ end trace ca143223eefdc828 ]---
because the random pools are still all zero. But it all still works
fine and causes no additional problems (which is the main goal of
instrumentation code).
Signed-off-by: Arjan van de Ven <arjan@linux.intel.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Diffstat (limited to 'net/nonet.c')
0 files changed, 0 insertions, 0 deletions