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.
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.
Eric
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.
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.
>
> 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.
>
Ok. After all this discussion looks like time to drop the patch. The
architectures which need page_size, they can modify vmlinux.ld.S to
embed the information in vmlinux.
Crash can do without pointer to crashing cpu's task_struct as well
(Though it is more work on crash's part). At the same time this information
can not possibly be captured in kernel reliably after the crash.
Identifying crashing cpu is important. Empty NT_KDUMPINFO would have done
the job but use of variables will avoid defining ABI. For the time being
crashing_cpu will do the job. Ofcourse this code is not robust enough to
handle stack overflow situations and that shall have to be taken care of.
Andrew, Could you please drop this patch from -mm.
kdumpx86-add-note-type-nt_kdumpinfo-to-kernel-core-dumps.patch
Thanks
Vivek
> Eric
> _______________________________________________
> fastboot mailing list
> [email protected]
> https://lists.osdl.org/mailman/listinfo/fastboot