[Crash-utility] Crash-utility Digest, Vol 137, Issue 17

[Dave Anderson]

----- Original Message -----
> >> >> crash> bt 30444
> >> >> PID: 30444 TASK: ffff8820454e9520 CPU: 19 COMMAND: "python"
> >> >> #0 [ffff88203de8b4f0] machine_kexec at ffffffff8103d1ab
> >> >> #1 [ffff88203de8b550] crash_kexec at ffffffff810cc4a2
> >> >> #2 [ffff88203de8b620] oops_end at ffffffff8153d540
> >> >> #3 [ffff88203de8b650] no_context at ffffffff8104e8cb
> >> >> #4 [ffff88203de8b6a0] __bad_area_nosemaphore at ffffffff8104eb55
> >> >> #5 [ffff88203de8b6f0] bad_area at ffffffff8104ec7e
> >> >> #6 [ffff88203de8b720] __do_page_fault at ffffffff8104f483
> >> >> #7 [ffff88203de8b840] do_page_fault at ffffffff8153f48e
> >> >> #8 [ffff88203de8b870] page_fault at ffffffff8153c835
> [exception RIP: list_del+27]
> RIP: ffffffff812a3f8b RSP: ffff88203de8b928 RFLAGS: 00010046
> RAX: 0000000000000006 RBX: ffffea006f040028 RCX: 0000000000000000
> RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffea006f040028
> RBP: ffff88203de8b938 R8: ffffea006f040028 R9: 0000000000000000
> R10: 0000000000000000 R11: 000000000000000a R12: 0000000000000000
> R13: ffff880000021de8 R14: 0000000000000020 R15: ffff880000019d80
> ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0000
> >> >> #9 [ffff88203de8b940] __rmqueue at ffffffff811336c3
> >> >> #10 [ffff88203de8b9e0] get_page_from_freelist at ffffffff81135350
> >> >> #11 [ffff88203de8bb10] __alloc_pages_nodemask at ffffffff81136ff9
> >> >> #12 [ffff88203de8bc60] alloc_pages_vma at ffffffff8117068a
> >> >> #13 [ffff88203de8bcb0] handle_pte_fault at ffffffff81152afd
> >> >> #14 [ffff88203de8bd90] handle_mm_fault at ffffffff81153179
> >> >> #15 [ffff88203de8be00] __do_page_fault at ffffffff8104f156
> >> >> #16 [ffff88203de8bf20] do_page_fault at ffffffff8153f48e
> >> >> #17 [ffff88203de8bf50] page_fault at ffffffff8153c835
> 
> Hi, everyone, this is the backtrace from the vmcore in my server. I remember
> there are some important functions between #13 ( handle_pte_fault ) and #12(
> handle_pte_fault ), like do_linear_fault(), do_nolinear_fault(),
> do_swap_page(), do_wp_page(). Why these functions cannot be printed in the
> backtrace? Is the compiler optimized for these functions？If so,how can I
> make sure the accurate function execution path. By the way, the crash
> version is crash 7.1.0-6.el6, and I use the centos-6.7 in my server.

In that kernel it appears that do_linear_fault(), do_nonlinear_fault() and
do_swap_page() are always inlined.  You can can verify that by checking whether
a function symbols exists:

  crash> sym do_linear_fault do_nonlinear_fault do_swap_page
  symbol not found: do_linear_fault
  possible alternatives:
    (none found)
  symbol not found: do_nonlinear_fault
  possible alternatives:
    (none found)
  symbol not found: do_swap_page
  possible alternatives:
    (none found)
  crash>

do_wp_page() does exist:

  crash> dis handle_pte_fault | grep call | grep do
  0xffffffff81141c0b <handle_pte_fault+139>:      callq  0xffffffff81141670 <__do_fault>
  0xffffffff81141c72 <handle_pte_fault+242>:      callq  0xffffffff81141670 <__do_fault>
  0xffffffff81141e48 <handle_pte_fault+712>:      callq  0xffffffff81140da0 <do_wp_page>
  0xffffffff8114214e <handle_pte_fault+1486>:     callq  0xffffffff8114c120 <do_page_add_anon_rmap>
  0xffffffff81142240 <handle_pte_fault+1728>:     callq  0xffffffff811638b0 <ksm_does_need_to_copy>
  0xffffffff811424e9 <handle_pte_fault+2409>:     callq  0xffffffff81140da0 <do_wp_page>
  crash>

Anyway, backtraces from the x86_64 "bt" command have never been guaranteed to be correct.
They have always been a best-estimate.

You can do a "bt -t" to show all of the possible text return addresses.
And you can do a "dis -rl <text-address-from-bt>" to show what was call
from each frame.  By doing that, you can get an accurate idea of what
path was taken.

Dave


> Thanks,
> Wind
> 
> --
> Crash-utility mailing list
> Crash-utility at redhat.com
> https://www.redhat.com/mailman/listinfo/crash-utility