On Mon, 3 Aug 2015 13:16:19 -0400 (EDT)
Dave Anderson <anderson(a)redhat.com> wrote:
----- Original Message -----
> On Mon, 03 Aug 2015 12:30:22 -0400
> Dave Anderson <anderson(a)prospeed.net> 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