[Crash-utility] [PATCH] Fix x86 initialization for {hard, soft}irq_ctx

[Dave Anderson]

----- Original Message -----
> Dave Anderson <anderson at redhat.com> writes:
> 
> >> >> crash> bt
> >> >> PID: 0      TASK: c1da8b00  CPU: 0   COMMAND: "swapper/0"
> >> >>  #0 [c1da1f60] __schedule at c19fe305
> >> >>  #1 [c1da1fa0] schedule at c19febb3
> >> >>  #2 [c1da1fac] schedule_preempt_disabled at c19ff0a2
> >> >>  #3 [c1da1fb4] cpu_startup_entry at c10a9580
> >> >> crash> bt 45
> >> >> PID: 45     TASK: f57d3a00  CPU: 3   COMMAND: "kworker/3:1"
> >> >> bt: cannot resolve stack trace:
> >> >> bt: Task in user space -- no backtrace
> >> >> 
> >> >> In above case, looks like failed to detect panic cpu, and "bt 45" also
> >> >> not working.
> >> 
> >> crash> bt 45
> >> PID: 45     TASK: f57d3a00  CPU: 3   COMMAND: "kworker/3:1"
> >> bt: cannot resolve stack trace:
> >> bt: Task in user space -- no backtrace
> 
> Debugged this case. The root cause is nested stack of softirq =>
> hardirq. Now doesn't handle it correctly, and the patch attacked.
> 
> BTW, with this patch, "bt -t" seems to be working at least. "bt" is
> failed sometime by confusion of stack-frame detection, this one is
> harder to fix.

OK thanks, I'll give this patch a test run.

> 
> [BTW, current x86_get_pc() uses inactive_task_frame_ret_addr to get
> pc. However, inactive_task_frame is only valid if task is sleeping
> state. (running task may overwrite inactive_task_frame already.)  I'm
> not sure whether we should check is_task_active() or not. Even if
> checking is_task_active(), we can't get pc correctly anyway.]

Well, x86_get_pc() should only be called in the case of sleeping
tasks because each dumpfile type has its own function to try to
find the active task registers.  For example, on a kdump:

  cmd_bt()
    back_trace()
      get_kdump_regs()
         get_netdump_regs()
            get_netdump_regs_x86()

get_netdump_regs_x86() *should* find the starting point hooks.
If it fails to do so, it will default to machdep->get_stack_frame()
and ultimately x86_get_pc().  So if it gets there, the backtrace
is pretty much guaranteed to be invalid.  

Thanks,
  Dave

 
> Thanks.
> --
> OGAWA Hirofumi <hirofumi at mail.parknet.co.jp>
> 
> 
> 
> [Text Documents:p1-fix-x86-nest-stack.patch]
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/x-diff
Size: 2061 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/crash-utility/attachments/20170217/1d8a2f46/attachment.bin>