Sorry. Reposting since it did not made to LKML due to my stupid mistake;
Also posting Dave Anderson's reponse:
Eric W. Biederman wrote:
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.
At present /proc/kcore writes the complete task structure for
NT_TASKSTRUCT note section. Thought it is the standard. Hence created
separate note section. The other option is the crash tool can directly
read "crashing_cpu variable" from the vmcore to determine the panic cpu.
Similarly, we can define panic_task variable in the kernel.
Dave Anderson ([email protected]) reponse:
" So does elf_core_dump() as well, but to gdb it's useless AFAICT...
Hey -- I wasn't even aware of the "crashing_cpu" variable.
That would work just fine.
Still a "panic_task", and perhaps even a "crash_page_size" variable
would be nice as well. No additional notes required...
Dave "
Basically, we can use some global structure in the kernel and dump any
needed information which we do not need to invoke any analysis tools
(crash, gdb). Dumping CPU control registers can also be done this way
without creating separate note section.
Thanks
Haren
Eric
------------------------------------------------------------------------
_______________________________________________
fastboot mailing list
[email protected]
https://lists.osdl.org/mailman/listinfo/fastboot
-
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]
| |
 |