Dave Anderson <[email protected]> writes:
> Just flagging the cpu, and then mapping that to the stack pointer found in
> the associated NT_PRSTATUS register set should work OK too. It gets
> a little muddy if it crashed while running on an IRQ stack, but it still can be
> tracked back from there as well. (although not if the crashing task overflowed
> the IRQ stack)
You can't track it back from the crashing cpu if the IRQ stack overflows
either. So I would rather have crash confused when trying to find the
task_struct. Then to have the kernel fail avoidably while attempting
to capture a core dump.
Even if you overflow the stack wit a bit of detective work it should still
be possible to show the stack overflowed and correct for it when analyzing
the crash dump. Doing anything like that from a crashing cpu (in a
reliable way) is very hard.
> The task_struct would be ideal though -- if the kernel's use of task_structs
> changes in the future, well, then crash is going to need a serious re-write
> anyway... FWIW, netdump and diskdump use the NT_TASKSTRUCT note
> note to store just the "current" pointer, and not the whole task_struct itself,
> which would just be a waste of space in the ELF header for crash's purposes.
> And looking at the gdb sources, it appears to be totally ignored. Who
> uses the NT_TASKSTRUCT note anyway?
Good question, especially as the kernel exports whatever we have for
a task struct today in the ELF note. No ABI compatibility is
maintained.
Given all of that I recommend an empty NT_TASKSTRUCT to flag the
crashing cpu, for now.
Eric
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
| |
 |