[Crash-utility] [PATCH] Fix warning: multiple active tasks have called die

[Dave Anderson]

----- Original Message -----

> > The current stack pointer is 9d7d3768 and the stack area is
> > [9d7d3768 - 9d7d4000]:
> > 
> > crash> bt -t | grep die
> >   [        9d7d38b8] die at 100f26
> >   [        9d7d3988] die at 100f26
> >   [        9d7d3a40] die at 100ee6
> >   [        9d7d3a90] die at 100f26
> > 
> > crash> rd 9d7d38b8
> >         9d7d38b8:  0000000000100f26                    .......&
> > crash> rd 9d7d3988
> >         9d7d3988:  0000000000100f26                    .......&
> > crash> rd 9d7d3a40
> >         9d7d3a40:  0000000000100ee6                    ........
> > crash> rd 9d7d3a90
> >         9d7d3a90:  0000000000100f26                    .......&
> 
> Given that the kernel cannot return from die() if panic_on_oops is set,
> and given the s390's PAGE_OFFSET of 0, I wonder if those values
> of 100f26 and 100ee6 possibly just fall into die()'s address range
> by "dumb luck", but have other uses/meanings?  If you disassemble
> the die() function, you could at least verify whether they are
> return addresses or not.

Well I should have looked ahead -- at least the 3 references to 100f26
appear to be the call to panic():

> >  #0 [9d7d37a8] __machine_kexec at 11d4fa
> >  #1 [9d7d37f0] smp_switch_to_ipl_cpu at 116ebe
> >  #2 [9d7d3860] machine_kexec at 11d49c
> >  #3 [9d7d3890] crash_kexec at 19ab26
> >  #4 [9d7d3960] panic at 5af192
> >  #5 [9d7d3a08] die at 100f26
> >  #6 [9d7d3a70] do_no_context at 11e910
> >  #7 [9d7d3aa8] do_protection_exception at 5b551a
> >  #8 [9d7d3bc0] pgm_exit at 5b34b8
> >  PSW:  0404100180000000 0000000000402d04 (sysrq_handle_crash+16)
> >  GPRS: 0000000000010000 00000000009c8c74 0000000000000001 0000000000000000
> >        00000000005af34e 00000000009c90e4 000000000091d3b0 0000000000a67960
> >        070000000016b628 0000000000000001 0000000000959530 0000000000000063
> >        00000000009596d0 0000000000606c60 000000000040309c 000000009d7d3d08
> >  #0 [9d7d3d70] process_one_work at 166abe
> >  #1 [9d7d3dd8] worker_thread at 1672da
> >  #2 [9d7d3e50] kthread at 1705b6
> >  #3 [9d7d3eb8] kernel_thread_starter at 5b2e3a

So I still cannot come up with a possible explanation of how there
could possibly be multiple instances of it (beyond the dumb luck
theory...)

Dave