On Mon, 3 Aug 2015 13:16:19 -0400 (EDT)
Dave Anderson <anderson@xxxxxxxxxx> wrote:
>
>
> ----- Original Message -----
> > On Mon, 03 Aug 2015 12:30:22 -0400
> > Dave Anderson <anderson@xxxxxxxxxxxx> wrote:
> >
> > >
> > >
> > > Ah, it must be because of the common user-kernel virtual address space on
> > > s390x?
> >
> > Yes we have overlapping virtual address ranges for kernel and user space and user
> > space registers are stored at the start of the kernel stack.
> >
> > But I am not sure, if that is the reason here (have to verify this).
> >
> > Doesn't the -t option check all the stack memory and looks for valid symbol
> > addresses? So IMO everything found there could be by chance the address
> > of panic. Why is this no problem on x86?
>
> I'm not sure what you mean. How could it be there by chance? Are you talking
> about a highly unlikely situation where a user-space exception frame at the top
> of the kernel stack happens to have a register containing a kernel virtual address
> that's within the panic() function?
My assumption was that in "print_stack_text_syms()" in the following loop
everything on the stack is checked for kernel symbols:
for (i = (esp - bt->stackbase)/sizeof(ulong);
i < LONGS_PER_STACK; i++) {
Besides of function call return addresses there are local variables on the
stack. If a variable "by chance" contains an address inside the "panic"
function, we will incorrectly assume that we have the panic task.
Is this understanding wrong?
Michael
--
Crash-utility mailing list
Crash-utility@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/crash-utility
