On Fri, Sep 23, 2005 at 01:12:23AM -0600, Eric W. Biederman wrote:
> Dave Anderson <[email protected]> writes:
>
> > So does elf_core_dump() as well, but to gdb it's useless AFAICT...
>
> We can always post_process things when generating a core dump
> if we have enough information.
>
> > 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...
>
> To avoid defining an ABI that we need to maintain there is some
> benefit in simply using static variables. But the form of the
> information really isn't the concern.
>
> Where we capture the information and how reliable is that capture
> is the concern.
>
> To capture page size the easiest and most reliable way I can see
> to do is to modify vmlinux.lds.S to contain something like:
> > _page_shift = PAGE_SHIFT;
> Giving you an absolute symbol _page_shift in vmlinux that
> contains the value you need, without overhead in the running
> kernel.
That's a cool idea. I just tested it.
[vivek@vivegoya linux]$ readelf -s vmlinux | grep __page_shift
28865: 0000000c 0 NOTYPE GLOBAL DEFAULT ABS __page_shift
>
> crashing_cpu makes sense to capture in some form, we definitely
> need to compute something that will allow us to write to
> a per cpu area on an SMP system.
>
> The big concern at this point is that the code has not undergone
> a serious stability audit. So it is the expectation that there
> is still code we can remove and modify to increase the likely hood
> of getting a crash dump.
>
> Currently we know that stack overflows sometimes happen and that
> they are a source of kernel crashes. It would be good if we could
> take a crash dump despite them. To do that requires code more
> robust than we have today. Quite likely it means that we will
> not be able to reliably capture the task_struct of the crashing cpu.
>
Agreed.
-
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]
| |
 |