Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

crash 7.1.9/Beagle Bone Black/Yocto 2.3 out of memory? #16

Open
RobertBerger opened this issue Jul 21, 2017 · 5 comments
Open

crash 7.1.9/Beagle Bone Black/Yocto 2.3 out of memory? #16

RobertBerger opened this issue Jul 21, 2017 · 5 comments

Comments

@RobertBerger
Copy link

Hi,

I built crash 7.1.9 for the Yocto project and make some experiments on a BeagleBone Black and it looks like it runs out of memory now and it's unusable.

crash 7.1.9
Copyright (C) 2002-2016  Red Hat, Inc.
Copyright (C) 2004, 2005, 2006, 2010  IBM Corporation
Copyright (C) 1999-2006  Hewlett-Packard Co
Copyright (C) 2005, 2006, 2011, 2012  Fujitsu Limited
Copyright (C) 2006, 2007  VA Linux Systems Japan K.K.
Copyright (C) 2005, 2011  NEC Corporation
Copyright (C) 1999, 2002, 2007  Silicon Graphics, Inc.
Copyright (C) 1999, 2000, 2001, 2002  Mission Critical Linux, Inc.
This program is free software, covered by the GNU General Public License,
and you are welcome to change it and/or distribute copies of it under
certain conditions.  Enter "help copying" to see the conditions.
This program has absolutely no warranty.  Enter "help warranty" for details.

GNU gdb (GDB) 7.6
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "arm-poky-linux-gnueabi"...

crash: vmlinux: Cannot allocate memory
      KERNEL: vmlinux
    DUMPFILE: /dev/mem
        CPUS: 1
        DATE: Mon May 29 12:03:54 2017
      UPTIME: 00:05:17
LOAD AVERAGE: 1.30, 1.17, 0.56
       TASKS: 94
    NODENAME: multi-v7-ml
     RELEASE: 4.9.36-custom-student-custom-ml-debug
     VERSION: #1 SMP Fri Jul 21 17:49:10 CEST 2017
     MACHINE: armv7l  (unknown Mhz)
      MEMORY: 510 MB
         PID: 631
     COMMAND: "crash"
        TASK: d9ed1000  [THREAD_INFO: d9c66000]
         CPU: 0
       STATE: TASK_RUNNING (ACTIVE)
crash> p jiffies
crash: fork system call failed: Cannot allocate memorycrash: cannot open pipe
crash> 

Am I doing something wrong?

Is this a known issue?

Last login: Mon May 29 11:59:59 2017
root@multi-v7-ml:~# cat /proc/meminfo
MemTotal:         486028 kB
MemFree:            3564 kB
MemAvailable:     150560 kB
Buffers:             184 kB
Cached:           145820 kB
SwapCached:            0 kB
Active:           334496 kB
Inactive:         120340 kB
Active(anon):     308900 kB
Inactive(anon):       92 kB
Active(file):      25596 kB
Inactive(file):   120248 kB
Unevictable:           0 kB
Mlocked:               0 kB
HighTotal:             0 kB
HighFree:              0 kB
LowTotal:         486028 kB
LowFree:            3564 kB
SwapTotal:             0 kB
SwapFree:              0 kB
Dirty:                 0 kB
Writeback:             0 kB
AnonPages:        308832 kB
Mapped:            16036 kB
Shmem:               164 kB
Slab:              21068 kB
SReclaimable:      11992 kB
SUnreclaim:         9076 kB
KernelStack:         760 kB
PageTables:         1300 kB
NFS_Unstable:          0 kB
Bounce:                0 kB
WritebackTmp:          0 kB
CommitLimit:      243012 kB
Committed_AS:     331640 kB
VmallocTotal:     516096 kB
VmallocUsed:           0 kB
VmallocChunk:          0 kB
CmaTotal:          65536 kB
CmaFree:               0 kB
root@multi-v7-ml:~# 
root@multi-v7-ml:/tmp# cp /proc/config.gz .
root@multi-v7-ml:/tmp# gunzip config.gz 
root@multi-v7-ml:/tmp# cat config | grep DEVMEM
CONFIG_DEVMEM=y
CONFIG_ARCH_HAS_DEVMEM_IS_ALLOWED=y
# CONFIG_STRICT_DEVMEM is not set
root@multi-v7-ml:/tmp# 
@crash-utility
Copy link
Collaborator

crash-utility commented Aug 7, 2017 via email

@RobertBerger
Copy link
Author

Hi Dave,

When I compile it on the target (the one with 512MB of physical memory) and 0 swap, as opposed to cross-compiling it with OE/Yocto it takes some time to compile;) but it runs happily and did so for quite some time - at least dating back to version 6.1.1 of crash.
The strange thing is that I can not quite figure out what makes the difference since when compiled on the target the 512MB RAM does not really seem to be a problem.
As soon as I'm back in the office I'll try with a board which has more RAM.

working version:

size -A -d crash
crash  :
section                  size      addr
.interp                    19     65876
.note.ABI-tag              32     65896
.note.gnu.build-id         36     65928
.gnu.hash               52796     65964
.dynsym                112848    118760
.dynstr                132280    231608
.gnu.version            14106    363888
.gnu.version_r            176    377996
.rel.dyn                  136    378172
.rel.plt                 2552    378308
.init                      12    380860
.plt                     3848    380872
.text                 3702756    384720
.fini                       8   4087476
.rodata               1324036   4087488
.ARM.exidx                  8   5411524
.eh_frame                   4   5411532
.init_array                 4   5480156
.fini_array                 4   5480160
.jcr                        4   5480164
.dynamic                  280   5480168
.got                     1296   5480448
.data                   69634   5481744
.bss                   440672   5551384
.comment                   17         0
.ARM.attributes            51         0
.debug_aranges          14200         0
.debug_info          17231425         0
.debug_abbrev          489910         0
.debug_line            980843         0
.debug_frame           373752         0
.debug_str             607368         0
.debug_loc            3694749         0
.debug_ranges          395800         0
Total                29645662

non working version:

size -A -d crash
crash  :
section                  size      addr
.interp                    19     65876
.note.ABI-tag              32     65896
.note.gnu.build-id         36     65928
.gnu.hash               44556     65964
.dynsym                112784    110520
.dynstr                132085    223304
.gnu.version            14098    355390
.gnu.version_r            144    369488
.rel.dyn                  136    369632
.rel.plt                 2504    369768
.init                      12    372272
.plt                     3776    372284
.text                 3704036    376064
.fini                       8   4080100
.rodata               1324336   4080112
.ARM.exidx                  8   5404448
.eh_frame                   4   5404456
.init_array                 4   5471972
.fini_array                 4   5471976
.jcr                        4   5471980
.dynamic                  272   5471984
.got                     1272   5472256
.data                   69626   5473528
.bss                   440664   5543160
.comment                   17         0
.ARM.attributes            51         0
.debug_aranges          14136         0
.debug_info          17231488         0
.debug_abbrev          490590         0
.debug_line           1088094         0
.debug_frame           376292         0
.debug_str             628462         0
.debug_loc            3696561         0
.debug_ranges          397408         0
Total                29773519

Of course the OE version contains those extra patches which might make the difference:

http://cgit.openembedded.org/meta-openembedded/tree/meta-oe/recipes-kernel/crash/crash

@RobertBerger
Copy link
Author

I just made a test on another platform with more memory and an update version of OE/Yocto (before I used 2.3 and now it's 2.3.1) and even the bitbaked version works happily.

crash 7.1.9
Copyright (C) 2002-2016  Red Hat, Inc.
Copyright (C) 2004, 2005, 2006, 2010  IBM Corporation
Copyright (C) 1999-2006  Hewlett-Packard Co
Copyright (C) 2005, 2006, 2011, 2012  Fujitsu Limited
Copyright (C) 2006, 2007  VA Linux Systems Japan K.K.
Copyright (C) 2005, 2011  NEC Corporation
Copyright (C) 1999, 2002, 2007  Silicon Graphics, Inc.
Copyright (C) 1999, 2000, 2001, 2002  Mission Critical Linux, Inc.
This program is free software, covered by the GNU General Public License,
and you are welcome to change it and/or distribute copies of it under
certain conditions.  Enter "help copying" to see the conditions.
This program has absolutely no warranty.  Enter "help warranty" for details.

GNU gdb (GDB) 7.6
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "arm-poky-linux-gnueabi"...


      KERNEL: vmlinux
    DUMPFILE: /dev/mem
        CPUS: 4
        DATE: Wed Aug 23 20:53:36 2017
      UPTIME: 00:04:44
LOAD AVERAGE: 1.13, 0.66, 0.28  
       TASKS: 128
    NODENAME: multi-v7-ml
     RELEASE: 4.9.44-custom-student-custom-ml-debug-dirty
     VERSION: #1 SMP Sun Aug 27 12:42:40 CEST 2017
     MACHINE: armv7l  (unknown Mhz)
      MEMORY: 1 GB
         PID: 650
     COMMAND: "crash"
        TASK: ec91b000  [THREAD_INFO: edec6000]
         CPU: 1
       STATE: TASK_RUNNING (ACTIVE)

crash>
crash>
crash>
crash> p jiffies
jiffies = $1 = 4280
crash> p jiffies
jiffies = $2 = 4707
cat /proc/meminfo
MemTotal:        1003536 kB
MemFree:          678948 kB
MemAvailable:     954460 kB
Buffers:              20 kB
Cached:           277876 kB
SwapCached:            0 kB
Active:           248448 kB
Inactive:          36064 kB
Active(anon):       6696 kB
Inactive(anon):       88 kB
Active(file):     241752 kB
Inactive(file):    35976 kB
Unevictable:           0 kB
Mlocked:               0 kB
HighTotal:        262144 kB
HighFree:         127948 kB
LowTotal:         741392 kB
LowFree:          551000 kB
SwapTotal:             0 kB
SwapFree:              0 kB
Dirty:                 0 kB
Writeback:             0 kB
AnonPages:          6500 kB
Mapped:            11840 kB
Shmem:               172 kB
Slab:              27988 kB
SReclaimable:      14028 kB
SUnreclaim:        13960 kB
KernelStack:         960 kB
PageTables:          668 kB
NFS_Unstable:          0 kB
Bounce:                0 kB
WritebackTmp:          0 kB
CommitLimit:      501768 kB
Committed_AS:      21604 kB
VmallocTotal:     245760 kB
VmallocUsed:           0 kB
VmallocChunk:          0 kB
CmaTotal:          65536 kB
CmaFree:           32524 kB

I'll keep on digging

@RobertBerger
Copy link
Author

With the board with 512 MB of RAM and the new setup (Yocto 2.3.1) and crash bitbaked it still does not work, similar to Yocto 2.3:

crash 7.1.9
Copyright (C) 2002-2016  Red Hat, Inc.
Copyright (C) 2004, 2005, 2006, 2010  IBM Corporation
Copyright (C) 1999-2006  Hewlett-Packard Co
Copyright (C) 2005, 2006, 2011, 2012  Fujitsu Limited
Copyright (C) 2006, 2007  VA Linux Systems Japan K.K.
Copyright (C) 2005, 2011  NEC Corporation
Copyright (C) 1999, 2002, 2007  Silicon Graphics, Inc.
Copyright (C) 1999, 2000, 2001, 2002  Mission Critical Linux, Inc.
This program is free software, covered by the GNU General Public License,
and you are welcome to change it and/or distribute copies of it under
certain conditions.  Enter "help copying" to see the conditions.
This program has absolutely no warranty.  Enter "help warranty" for details.

GNU gdb (GDB) 7.6
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "arm-poky-linux-gnueabi"...

crash: vmlinux: Cannot allocate memory
      KERNEL: vmlinux
    DUMPFILE: /dev/mem
        CPUS: 1
        DATE: Wed Aug 23 20:15:20 2017
      UPTIME: 00:05:55
LOAD AVERAGE: 1.35, 1.28, 0.63
       TASKS: 99
    NODENAME: multi-v7-ml
     RELEASE: 4.9.44-custom-student-custom-ml-debug
     VERSION: #1 SMP Sun Aug 27 14:15:36 CEST 2017
     MACHINE: armv7l  (unknown Mhz)
      MEMORY: 510 MB
         PID: 659
     COMMAND: "crash"
        TASK: d9dc1000  [THREAD_INFO: d9a14000]
         CPU: 0
       STATE: TASK_RUNNING (ACTIVE)

crash> p jiffies
crash: fork system call failed: Cannot allocate memorycrash: cannot open pipe
crash> 
cat /proc/meminfo
MemTotal:         486028 kB
MemFree:          306664 kB
MemAvailable:     453000 kB
Buffers:             240 kB
Cached:           144744 kB
SwapCached:            0 kB
Active:            33264 kB
Inactive:         118324 kB
Active(anon):       6692 kB
Inactive(anon):       92 kB
Active(file):      26572 kB
Inactive(file):   118232 kB
Unevictable:           0 kB
Mlocked:               0 kB
HighTotal:             0 kB
HighFree:              0 kB
LowTotal:         486028 kB
LowFree:          306664 kB
SwapTotal:             0 kB
SwapFree:              0 kB
Dirty:                 0 kB
Writeback:             0 kB
AnonPages:          6632 kB
Mapped:            11708 kB
Shmem:               172 kB
Slab:              21528 kB
SReclaimable:      12372 kB
SUnreclaim:         9156 kB
KernelStack:         784 kB
PageTables:          668 kB
NFS_Unstable:          0 kB
Bounce:                0 kB
WritebackTmp:          0 kB
CommitLimit:      243012 kB
Committed_AS:      22880 kB
VmallocTotal:     516096 kB
VmallocUsed:           0 kB
VmallocChunk:          0 kB
CmaTotal:          65536 kB
CmaFree:           32700 kB

@RobertBerger
Copy link
Author

And crash built on the target seems to work.

took some time to build it:

real    165m59.071s
user    58m26.725s
sys     34m53.630s

but:

crash 7.1.9
Copyright (C) 2002-2016  Red Hat, Inc.
Copyright (C) 2004, 2005, 2006, 2010  IBM Corporation
Copyright (C) 1999-2006  Hewlett-Packard Co
Copyright (C) 2005, 2006, 2011, 2012  Fujitsu Limited
Copyright (C) 2006, 2007  VA Linux Systems Japan K.K.
Copyright (C) 2005, 2011  NEC Corporation
Copyright (C) 1999, 2002, 2007  Silicon Graphics, Inc.
Copyright (C) 1999, 2000, 2001, 2002  Mission Critical Linux, Inc.
This program is free software, covered by the GNU General Public License,
and you are welcome to change it and/or distribute copies of it under
certain conditions.  Enter "help copying" to see the conditions.
This program has absolutely no warranty.  Enter "help warranty" for details.

GNU gdb (GDB) 7.6
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "armv7l-unknown-linux-gnueabi"...

      KERNEL: vmlinux
    DUMPFILE: /dev/mem
        CPUS: 1
        DATE: Wed Aug 23 23:37:06 2017
      UPTIME: 03:27:41
LOAD AVERAGE: 1.26, 1.17, 0.78
       TASKS: 99
    NODENAME: multi-v7-ml
     RELEASE: 4.9.44-custom-student-custom-ml-debug
     VERSION: #1 SMP Sun Aug 27 14:15:36 CEST 2017
     MACHINE: armv7l  (unknown Mhz)
      MEMORY: 510 MB
         PID: 31613
     COMMAND: "crash"
        TASK: da895000  [THREAD_INFO: cba4e000]
         CPU: 0
       STATE: TASK_RUNNING (ACTIVE)

crash>
crash> p jiffies
jiffies = $1 = 3391350
crash> 

yangh added a commit to yangh/crash that referenced this issue Nov 15, 2021
Overflow stack supported since kernel 4.14 in commit 872d8327ce8,
without this patch, bt command trigger a SIGSEGV fault due the SP
pointed to the overflow stack which not yet loaded by crash.

Before:

      KERNEL: ../vmlinux
    DUMPFILE: la_guestdump.gcore
        CPUS: 8
        DATE: Tue Jul 13 19:59:44 CST 2021
      UPTIME: 00:00:42
LOAD AVERAGE: 3.99, 1.13, 0.39
       TASKS: 1925
    NODENAME: localhost
     RELEASE: 4.14.156+
     VERSION: crash-utility#1 SMP PREEMPT Tue Jul 13 10:37:23 UTC 2021
     MACHINE: aarch64  (unknown Mhz)
      MEMORY: 8.7 GB
       PANIC: "Kernel panic - not syncing: kernel stack overflow"
         PID: 1969
     COMMAND: "irq/139-0-0024"
        TASK: ffffffcc1a230000  [THREAD_INFO: ffffffcc1a230000]
         CPU: 0
       STATE: TASK_RUNNING (PANIC)

crash-7.3.0> bt
PID: 1969   TASK: ffffffcc1a230000  CPU: 0   COMMAND: "irq/139-0-0024"
Segmentation fault (core dumped)

After:

crash> bt
PID: 1969   TASK: ffffffcc1a230000  CPU: 0   COMMAND: "irq/139-0-0024"
  #0 [ffffffcc7fd5cf50] __delay at ffffff8008c80774
  crash-utility#1 [ffffffcc7fd5cf60] __const_udelay at ffffff8008c80864
  crash-utility#2 [ffffffcc7fd5cf80] msm_trigger_wdog_bite at ffffff80084e9430
  crash-utility#3 [ffffffcc7fd5cfa0] do_vm_restart at ffffff80087bc974
  crash-utility#4 [ffffffcc7fd5cfc0] machine_restart at ffffff80080856fc
  crash-utility#5 [ffffffcc7fd5cfd0] emergency_restart at ffffff80080d49bc
  crash-utility#6 [ffffffcc7fd5d140] panic at ffffff80080af4c0
  crash-utility#7 [ffffffcc7fd5d150] nmi_panic at ffffff80080af150
  crash-utility#8 [ffffffcc7fd5d190] handle_bad_stack at ffffff800808b0b8
  crash-utility#9 [ffffffcc7fd5d2d0] __bad_stack at ffffff800808285c
--- <IRQ stack> ---
 crash-utility#10 [ffffff801187bc60] el1_error_invalid at ffffff8008082e7c
 crash-utility#11 [ffffff801187bcc0] cyttsp6_mt_attention at ffffff8000e8498c [cyttsp6]
 crash-utility#12 [ffffff801187bd20] call_atten_cb at ffffff8000e82030 [cyttsp6]
 crash-utility#13 [ffffff801187bdc0] cyttsp6_irq at ffffff8000e81e34 [cyttsp6]
 crash-utility#14 [ffffff801187bdf0] irq_thread_fn at ffffff8008128dd8
 crash-utility#15 [ffffff801187be50] irq_thread at ffffff8008128ca4
 crash-utility#16 [ffffff801187beb0] kthread at ffffff80080d2fc4
crash>

Signed-off-by: Hong YANG <[email protected]>
k-hagio pushed a commit that referenced this issue Dec 9, 2022
We met "bt" command on KASAN kernel vmcore display truncated backtraces
like this:

  crash> bt
  PID: 4131   TASK: ffff8001521df000  CPU: 3   COMMAND: "bash"
   #0 [ffff2000224b0cb0] machine_kexec_prepare at ffff2000200bff4c

After digging the root cause, it turns out that arm64_in_kdump_text()
found wrong bt->bptr at "machine_kexec" branch.

Disassemble machine_kexec() of KASAN vmlinux (gcc 7.3.0):

  crash> dis -x machine_kexec
  0xffff2000200bff50 <machine_kexec>:     stp     x29, x30, [sp,#-208]!
  0xffff2000200bff54 <machine_kexec+0x4>: mov     x29, sp
  0xffff2000200bff58 <machine_kexec+0x8>: stp     x19, x20, [sp,#16]
  0xffff2000200bff5c <machine_kexec+0xc>: str     x24, [sp,#56]
  0xffff2000200bff60 <machine_kexec+0x10>:        str     x26, [sp,#72]
  0xffff2000200bff64 <machine_kexec+0x14>:        mov     x2, #0x8ab3
  0xffff2000200bff68 <machine_kexec+0x18>:        add     x1, x29, #0x70
  0xffff2000200bff6c <machine_kexec+0x1c>:        lsr     x1, x1, #3
  0xffff2000200bff70 <machine_kexec+0x20>:        movk    x2, #0x41b5, lsl #16
  0xffff2000200bff74 <machine_kexec+0x24>:        mov     x19, #0x200000000000
  0xffff2000200bff78 <machine_kexec+0x28>:        adrp    x3, 0xffff2000224b0000
  0xffff2000200bff7c <machine_kexec+0x2c>:        movk    x19, #0xdfff, lsl #48
  0xffff2000200bff80 <machine_kexec+0x30>:        add     x3, x3, #0xcb0
  0xffff2000200bff84 <machine_kexec+0x34>:        add     x4, x1, x19
  0xffff2000200bff88 <machine_kexec+0x38>:        stp     x2, x3, [x29,#112]
  0xffff2000200bff8c <machine_kexec+0x3c>:        adrp    x2, 0xffff2000200bf000 <swsusp_arch_resume+0x1e8>
  0xffff2000200bff90 <machine_kexec+0x40>:        add     x2, x2, #0xf50
  0xffff2000200bff94 <machine_kexec+0x44>:        str     x2, [x29,#128]
  0xffff2000200bff98 <machine_kexec+0x48>:        mov     w2, #0xf1f1f1f1
  0xffff2000200bff9c <machine_kexec+0x4c>:        str     w2, [x1,x19]
  0xffff2000200bffa0 <machine_kexec+0x50>:        mov     w2, #0xf200
  0xffff2000200bffa4 <machine_kexec+0x54>:        mov     w1, #0xf3f3f3f3
  0xffff2000200bffa8 <machine_kexec+0x58>:        movk    w2, #0xf2f2, lsl #16
  0xffff2000200bffac <machine_kexec+0x5c>:        stp     w2, w1, [x4,#4]

We notice that:
1. machine_kexec() start address is 0xffff2000200bff50
2. the instruction at machine_kexec+0x44 stores the same value
   0xffff2000200bff50 (comes from 0xffff2000200bf000 + 0xf50)
   into stack postion [x29,#128].

When arm64_in_kdump_text() searches for LR from stack, it met
0xffff2000200bff50 firstly, so got wrong bt->bptr.

We know that the real LR is always greater than the start address
of a function, so let's fix it by changing the search conditon to
(*ptr > xxx_start) && (*ptr < xxx_end).

Signed-off-by: Ding Hui <[email protected]>
k-hagio pushed a commit that referenced this issue Feb 14, 2023
Currently, the "bt" command may print a bogus exception frame
and the remaining frame will be truncated on x86_64 when using the
"virsh send-key <kvm guest> KEY_LEFTALT KEY_SYSRQ KEY_C" command
to trigger a panic from the KVM host. For example:

  crash> bt
  PID: 0        TASK: ffff9e7a47e32f00  CPU: 3    COMMAND: "swapper/3"
   #0 [ffffba7900118bb8] machine_kexec at ffffffff87e5c2c7
   #1 [ffffba7900118c08] __crash_kexec at ffffffff87f9500d
   #2 [ffffba7900118cd0] panic at ffffffff87edfff9
   #3 [ffffba7900118d50] sysrq_handle_crash at ffffffff883ce2c1
   ...
   #16 [ffffba7900118fd8] handle_edge_irq at ffffffff87f559f2
   #17 [ffffba7900118ff0] asm_call_on_stack at ffffffff88800fa2
   --- <IRQ stack> ---
   #18 [ffffba790008bda0] asm_call_on_stack at ffffffff88800fa2
       RIP: ffffffffffffffff  RSP: 0000000000000124  RFLAGS: 00000003
       RAX: 0000000000000000  RBX: 0000000000000001  RCX: 0000000000000000
       RDX: ffffffff88800c1e  RSI: 0000000000000000  RDI: 0000000000000000
       RBP: 0000000000000001   R8: 0000000000000000   R9: 0000000000000000
       R10: 0000000000000000  R11: ffffffff88760555  R12: ffffba790008be08
       R13: ffffffff87f18002  R14: ffff9e7a47e32f00  R15: ffff9e7bb6198e00
       ORIG_RAX: 0000000000000000  CS: 0003  SS: 0000
  bt: WARNING: possibly bogus exception frame
  crash>

The following related kernel commits cause the current issue, crash
needs to adjust the value of irq_eframe_link.

Related kernel commits:
[1] v5.8: 931b94145981 ("x86/entry: Provide helpers for executing on the irqstack")
[2] v5.8: fa5e5c409213 ("x86/entry: Use idtentry for interrupts")
[3] v5.12: 52d743f3b712 ("x86/softirq: Remove indirection in do_softirq_own_stack()")

Signed-off-by: Lianbo Jiang <[email protected]>
Signed-off-by: Kazuhito Hagio <[email protected]>
k-hagio pushed a commit that referenced this issue Nov 29, 2023
…usly

There is an issue that, for kernel modules, "dis -rl" fails to display
modules code line number data after execute "bt" command in crash.

Without the patch:
  crsah> mod -S
  crash> bt
  PID: 1500     TASK: ff2bd8b093524000  CPU: 16   COMMAND: "lpfc_worker_0"
   #0 [ff2c9f725c39f9e0] machine_kexec at ffffffff8e0686d3
   ...snip...
   #8 [ff2c9f725c39fcc0] __lpfc_sli_release_iocbq_s4 at ffffffffc0f2f425 [lpfc]
   ...snip...
  crash> dis -rl ffffffffc0f60f82
  0xffffffffc0f60eb0 <lpfc_nlp_get>:      nopl   0x0(%rax,%rax,1) [FTRACE NOP]
  0xffffffffc0f60eb5 <lpfc_nlp_get+5>:    push   %rbp
  0xffffffffc0f60eb6 <lpfc_nlp_get+6>:    push   %rbx
  0xffffffffc0f60eb7 <lpfc_nlp_get+7>:    test   %rdi,%rdi

With the patch:
  crash> mod -S
  crash> bt
  PID: 1500     TASK: ff2bd8b093524000  CPU: 16   COMMAND: "lpfc_worker_0"
   #0 [ff2c9f725c39f9e0] machine_kexec at ffffffff8e0686d3
   ...snip...
   #8 [ff2c9f725c39fcc0] __lpfc_sli_release_iocbq_s4 at ffffffffc0f2f425 [lpfc]
   ...snip...
  crash> dis -rl ffffffffc0f60f82
  /usr/src/debug/kernel-4.18.0-425.13.1.el8_7/linux-4.18.0-425.13.1.el8_7.x86_64/drivers/scsi/lpfc/lpfc_hbadisc.c: 6756
  0xffffffffc0f60eb0 <lpfc_nlp_get>:      nopl   0x0(%rax,%rax,1) [FTRACE NOP]
  /usr/src/debug/kernel-4.18.0-425.13.1.el8_7/linux-4.18.0-425.13.1.el8_7.x86_64/drivers/scsi/lpfc/lpfc_hbadisc.c: 6759
  0xffffffffc0f60eb5 <lpfc_nlp_get+5>:    push   %rbp

The root cause is, after kernel module been loaded by mod command, the symtable
is not expanded in gdb side. crash bt or dis command will trigger such an
expansion. However the symtable expansion is different for the 2 commands:

The stack trace of "dis -rl" for symtable expanding:

  #0  0x00000000008d8d9f in add_compunit_symtab_to_objfile ...
  #1  0x00000000006d3293 in buildsym_compunit::end_symtab_with_blockvector ...
  #2  0x00000000006d336a in buildsym_compunit::end_symtab_from_static_block ...
  #3  0x000000000077e8e9 in process_full_comp_unit ...
  #4  process_queue ...
  #5  dw2_do_instantiate_symtab ...
  #6  0x000000000077ed67 in dw2_instantiate_symtab ...
  #7  0x000000000077f75e in dw2_expand_all_symtabs ...
  #8  0x00000000008f254d in gdb_get_line_number ...
  #9  0x00000000008f22af in gdb_command_funnel_1 ...
  #10 0x00000000008f2003 in gdb_command_funnel ...
  #11 0x00000000005b7f02 in gdb_interface ...
  #12 0x00000000005f5bd8 in get_line_number ...
  #13 0x000000000059e574 in cmd_dis ...

The stack trace of "bt" for symtable expanding:

  #0  0x00000000008d8d9f in add_compunit_symtab_to_objfile ...
  #1  0x00000000006d3293 in buildsym_compunit::end_symtab_with_blockvector ...
  #2  0x00000000006d336a in buildsym_compunit::end_symtab_from_static_block ...
  #3  0x000000000077e8e9 in process_full_comp_unit ...
  #4  process_queue ...
  #5  dw2_do_instantiate_symtab ...
  #6  0x000000000077ed67 in dw2_instantiate_symtab ...
  #7  0x000000000077f8ed in dw2_lookup_symbol ...
  #8  0x00000000008e6d03 in lookup_symbol_via_quick_fns ...
  #9  0x00000000008e7153 in lookup_symbol_in_objfile ...
  #10 0x00000000008e73c6 in lookup_symbol_global_or_static_iterator_cb ...
  #11 0x00000000008b99c4 in svr4_iterate_over_objfiles_in_search_order ...
  #12 0x00000000008e754e in lookup_global_or_static_symbol ...
  #13 0x00000000008e75da in lookup_static_symbol ...
  #14 0x00000000008e632c in lookup_symbol_aux ...
  #15 0x00000000008e5a7a in lookup_symbol_in_language ...
  #16 0x00000000008e5b30 in lookup_symbol ...
  #17 0x00000000008f2a4a in gdb_get_datatype ...
  #18 0x00000000008f22c0 in gdb_command_funnel_1 ...
  #19 0x00000000008f2003 in gdb_command_funnel ...
  #20 0x00000000005b7f02 in gdb_interface ...
  #21 0x00000000005f8a9f in datatype_info ...
  #22 0x0000000000599947 in cpu_map_size ...
  #23 0x00000000005a975d in get_cpus_online ...
  #24 0x0000000000637a8b in diskdump_get_prstatus_percpu ...
  #25 0x000000000062f0e4 in get_netdump_regs_x86_64 ...
  #26 0x000000000059fe68 in back_trace ...
  #27 0x00000000005ab1cb in cmd_bt ...

For the stacktrace of "dis -rl", it calls dw2_expand_all_symtabs() to expand
all symtable of the objfile, or "*.ko.debug" in our case. However for
the stacktrace of "bt", it doesn't expand all, but only a subset of symtable
which is enough to find a symbol by dw2_lookup_symbol(). As a result, the
objfile->compunit_symtabs, which is the head of a single linked list of
struct compunit_symtab, is not NULL but didn't contain all symtables. It
will not be reinitialized in gdb_get_line_number() by "dis -rl" because
!objfile_has_full_symbols(objfile) check will fail, so it cannot display
the proper code line number data.

Since objfile_has_full_symbols(objfile) check cannot ensure all symbols
been expanded, this patch add a new member as a flag for struct objfile
to record if all symbols have been expanded. The flag will be set only ofter
expand_all_symtabs been called.

Signed-off-by: Tao Liu <[email protected]>
liutgnu added a commit to liutgnu/crash-preview that referenced this issue Nov 30, 2023
…usly

There is an issue that, for kernel modules, "dis -rl" fails to display
modules code line number data after execute "bt" command in crash.

Without the patch:
  crsah> mod -S
  crash> bt
  PID: 1500     TASK: ff2bd8b093524000  CPU: 16   COMMAND: "lpfc_worker_0"
   #0 [ff2c9f725c39f9e0] machine_kexec at ffffffff8e0686d3
   ...snip...
   crash-utility#8 [ff2c9f725c39fcc0] __lpfc_sli_release_iocbq_s4 at ffffffffc0f2f425 [lpfc]
   ...snip...
  crash> dis -rl ffffffffc0f60f82
  0xffffffffc0f60eb0 <lpfc_nlp_get>:      nopl   0x0(%rax,%rax,1) [FTRACE NOP]
  0xffffffffc0f60eb5 <lpfc_nlp_get+5>:    push   %rbp
  0xffffffffc0f60eb6 <lpfc_nlp_get+6>:    push   %rbx
  0xffffffffc0f60eb7 <lpfc_nlp_get+7>:    test   %rdi,%rdi

With the patch:
  crash> mod -S
  crash> bt
  PID: 1500     TASK: ff2bd8b093524000  CPU: 16   COMMAND: "lpfc_worker_0"
   #0 [ff2c9f725c39f9e0] machine_kexec at ffffffff8e0686d3
   ...snip...
   crash-utility#8 [ff2c9f725c39fcc0] __lpfc_sli_release_iocbq_s4 at ffffffffc0f2f425 [lpfc]
   ...snip...
  crash> dis -rl ffffffffc0f60f82
  /usr/src/debug/kernel-4.18.0-425.13.1.el8_7/linux-4.18.0-425.13.1.el8_7.x86_64/drivers/scsi/lpfc/lpfc_hbadisc.c: 6756
  0xffffffffc0f60eb0 <lpfc_nlp_get>:      nopl   0x0(%rax,%rax,1) [FTRACE NOP]
  /usr/src/debug/kernel-4.18.0-425.13.1.el8_7/linux-4.18.0-425.13.1.el8_7.x86_64/drivers/scsi/lpfc/lpfc_hbadisc.c: 6759
  0xffffffffc0f60eb5 <lpfc_nlp_get+5>:    push   %rbp

The root cause is, after kernel module been loaded by mod command, the symtable
is not expanded in gdb side. crash bt or dis command will trigger such an
expansion. However the symtable expansion is different for the 2 commands:

The stack trace of "dis -rl" for symtable expanding:

  #0  0x00000000008d8d9f in add_compunit_symtab_to_objfile ...
  crash-utility#1  0x00000000006d3293 in buildsym_compunit::end_symtab_with_blockvector ...
  crash-utility#2  0x00000000006d336a in buildsym_compunit::end_symtab_from_static_block ...
  crash-utility#3  0x000000000077e8e9 in process_full_comp_unit ...
  crash-utility#4  process_queue ...
  crash-utility#5  dw2_do_instantiate_symtab ...
  crash-utility#6  0x000000000077ed67 in dw2_instantiate_symtab ...
  crash-utility#7  0x000000000077f75e in dw2_expand_all_symtabs ...
  crash-utility#8  0x00000000008f254d in gdb_get_line_number ...
  crash-utility#9  0x00000000008f22af in gdb_command_funnel_1 ...
  crash-utility#10 0x00000000008f2003 in gdb_command_funnel ...
  crash-utility#11 0x00000000005b7f02 in gdb_interface ...
  crash-utility#12 0x00000000005f5bd8 in get_line_number ...
  crash-utility#13 0x000000000059e574 in cmd_dis ...

The stack trace of "bt" for symtable expanding:

  #0  0x00000000008d8d9f in add_compunit_symtab_to_objfile ...
  crash-utility#1  0x00000000006d3293 in buildsym_compunit::end_symtab_with_blockvector ...
  crash-utility#2  0x00000000006d336a in buildsym_compunit::end_symtab_from_static_block ...
  crash-utility#3  0x000000000077e8e9 in process_full_comp_unit ...
  crash-utility#4  process_queue ...
  crash-utility#5  dw2_do_instantiate_symtab ...
  crash-utility#6  0x000000000077ed67 in dw2_instantiate_symtab ...
  crash-utility#7  0x000000000077f8ed in dw2_lookup_symbol ...
  crash-utility#8  0x00000000008e6d03 in lookup_symbol_via_quick_fns ...
  crash-utility#9  0x00000000008e7153 in lookup_symbol_in_objfile ...
  crash-utility#10 0x00000000008e73c6 in lookup_symbol_global_or_static_iterator_cb ...
  crash-utility#11 0x00000000008b99c4 in svr4_iterate_over_objfiles_in_search_order ...
  crash-utility#12 0x00000000008e754e in lookup_global_or_static_symbol ...
  crash-utility#13 0x00000000008e75da in lookup_static_symbol ...
  crash-utility#14 0x00000000008e632c in lookup_symbol_aux ...
  crash-utility#15 0x00000000008e5a7a in lookup_symbol_in_language ...
  crash-utility#16 0x00000000008e5b30 in lookup_symbol ...
  crash-utility#17 0x00000000008f2a4a in gdb_get_datatype ...
  crash-utility#18 0x00000000008f22c0 in gdb_command_funnel_1 ...
  crash-utility#19 0x00000000008f2003 in gdb_command_funnel ...
  crash-utility#20 0x00000000005b7f02 in gdb_interface ...
  crash-utility#21 0x00000000005f8a9f in datatype_info ...
  crash-utility#22 0x0000000000599947 in cpu_map_size ...
  crash-utility#23 0x00000000005a975d in get_cpus_online ...
  crash-utility#24 0x0000000000637a8b in diskdump_get_prstatus_percpu ...
  crash-utility#25 0x000000000062f0e4 in get_netdump_regs_x86_64 ...
  crash-utility#26 0x000000000059fe68 in back_trace ...
  crash-utility#27 0x00000000005ab1cb in cmd_bt ...

For the stacktrace of "dis -rl", it calls dw2_expand_all_symtabs() to expand
all symtable of the objfile, or "*.ko.debug" in our case. However for
the stacktrace of "bt", it doesn't expand all, but only a subset of symtable
which is enough to find a symbol by dw2_lookup_symbol(). As a result, the
objfile->compunit_symtabs, which is the head of a single linked list of
struct compunit_symtab, is not NULL but didn't contain all symtables. It
will not be reinitialized in gdb_get_line_number() by "dis -rl" because
!objfile_has_full_symbols(objfile) check will fail, so it cannot display
the proper code line number data.

Since objfile_has_full_symbols(objfile) check cannot ensure all symbols
been expanded, this patch add a new member as a flag for struct objfile
to record if all symbols have been expanded. The flag will be set only ofter
expand_all_symtabs been called.

Signed-off-by: Tao Liu <[email protected]>
liutgnu added a commit to liutgnu/crash-preview that referenced this issue Dec 1, 2023
…eviously

There is an issue that, for kernel modules, "dis -rl" fails to display
modules code line number data after execute "bt" command in crash.

Without the patch:
  crsah> mod -S
  crash> bt
  PID: 1500     TASK: ff2bd8b093524000  CPU: 16   COMMAND: "lpfc_worker_0"
   #0 [ff2c9f725c39f9e0] machine_kexec at ffffffff8e0686d3
   ...snip...
   crash-utility#8 [ff2c9f725c39fcc0] __lpfc_sli_release_iocbq_s4 at ffffffffc0f2f425 [lpfc]
   ...snip...
  crash> dis -rl ffffffffc0f60f82
  0xffffffffc0f60eb0 <lpfc_nlp_get>:      nopl   0x0(%rax,%rax,1) [FTRACE NOP]
  0xffffffffc0f60eb5 <lpfc_nlp_get+5>:    push   %rbp
  0xffffffffc0f60eb6 <lpfc_nlp_get+6>:    push   %rbx
  0xffffffffc0f60eb7 <lpfc_nlp_get+7>:    test   %rdi,%rdi

With the patch:
  crash> mod -S
  crash> bt
  PID: 1500     TASK: ff2bd8b093524000  CPU: 16   COMMAND: "lpfc_worker_0"
   #0 [ff2c9f725c39f9e0] machine_kexec at ffffffff8e0686d3
   ...snip...
   crash-utility#8 [ff2c9f725c39fcc0] __lpfc_sli_release_iocbq_s4 at ffffffffc0f2f425 [lpfc]
   ...snip...
  crash> dis -rl ffffffffc0f60f82
  /usr/src/debug/kernel-4.18.0-425.13.1.el8_7/linux-4.18.0-425.13.1.el8_7.x86_64/drivers/scsi/lpfc/lpfc_hbadisc.c: 6756
  0xffffffffc0f60eb0 <lpfc_nlp_get>:      nopl   0x0(%rax,%rax,1) [FTRACE NOP]
  /usr/src/debug/kernel-4.18.0-425.13.1.el8_7/linux-4.18.0-425.13.1.el8_7.x86_64/drivers/scsi/lpfc/lpfc_hbadisc.c: 6759
  0xffffffffc0f60eb5 <lpfc_nlp_get+5>:    push   %rbp

The root cause is, after kernel module been loaded by mod command, the symtable
is not expanded in gdb side. crash bt or dis command will trigger such an
expansion. However the symtable expansion is different for the 2 commands:

The stack trace of "dis -rl" for symtable expanding:

  #0  0x00000000008d8d9f in add_compunit_symtab_to_objfile ...
  crash-utility#1  0x00000000006d3293 in buildsym_compunit::end_symtab_with_blockvector ...
  crash-utility#2  0x00000000006d336a in buildsym_compunit::end_symtab_from_static_block ...
  crash-utility#3  0x000000000077e8e9 in process_full_comp_unit ...
  crash-utility#4  process_queue ...
  crash-utility#5  dw2_do_instantiate_symtab ...
  crash-utility#6  0x000000000077ed67 in dw2_instantiate_symtab ...
  crash-utility#7  0x000000000077f75e in dw2_expand_all_symtabs ...
  crash-utility#8  0x00000000008f254d in gdb_get_line_number ...
  crash-utility#9  0x00000000008f22af in gdb_command_funnel_1 ...
  crash-utility#10 0x00000000008f2003 in gdb_command_funnel ...
  crash-utility#11 0x00000000005b7f02 in gdb_interface ...
  crash-utility#12 0x00000000005f5bd8 in get_line_number ...
  crash-utility#13 0x000000000059e574 in cmd_dis ...

The stack trace of "bt" for symtable expanding:

  #0  0x00000000008d8d9f in add_compunit_symtab_to_objfile ...
  crash-utility#1  0x00000000006d3293 in buildsym_compunit::end_symtab_with_blockvector ...
  crash-utility#2  0x00000000006d336a in buildsym_compunit::end_symtab_from_static_block ...
  crash-utility#3  0x000000000077e8e9 in process_full_comp_unit ...
  crash-utility#4  process_queue ...
  crash-utility#5  dw2_do_instantiate_symtab ...
  crash-utility#6  0x000000000077ed67 in dw2_instantiate_symtab ...
  crash-utility#7  0x000000000077f8ed in dw2_lookup_symbol ...
  crash-utility#8  0x00000000008e6d03 in lookup_symbol_via_quick_fns ...
  crash-utility#9  0x00000000008e7153 in lookup_symbol_in_objfile ...
  crash-utility#10 0x00000000008e73c6 in lookup_symbol_global_or_static_iterator_cb ...
  crash-utility#11 0x00000000008b99c4 in svr4_iterate_over_objfiles_in_search_order ...
  crash-utility#12 0x00000000008e754e in lookup_global_or_static_symbol ...
  crash-utility#13 0x00000000008e75da in lookup_static_symbol ...
  crash-utility#14 0x00000000008e632c in lookup_symbol_aux ...
  crash-utility#15 0x00000000008e5a7a in lookup_symbol_in_language ...
  crash-utility#16 0x00000000008e5b30 in lookup_symbol ...
  crash-utility#17 0x00000000008f2a4a in gdb_get_datatype ...
  crash-utility#18 0x00000000008f22c0 in gdb_command_funnel_1 ...
  crash-utility#19 0x00000000008f2003 in gdb_command_funnel ...
  crash-utility#20 0x00000000005b7f02 in gdb_interface ...
  crash-utility#21 0x00000000005f8a9f in datatype_info ...
  crash-utility#22 0x0000000000599947 in cpu_map_size ...
  crash-utility#23 0x00000000005a975d in get_cpus_online ...
  crash-utility#24 0x0000000000637a8b in diskdump_get_prstatus_percpu ...
  crash-utility#25 0x000000000062f0e4 in get_netdump_regs_x86_64 ...
  crash-utility#26 0x000000000059fe68 in back_trace ...
  crash-utility#27 0x00000000005ab1cb in cmd_bt ...

For the stacktrace of "dis -rl", it calls dw2_expand_all_symtabs() to expand
all symtable of the objfile, or "*.ko.debug" in our case. However for
the stacktrace of "bt", it doesn't expand all, but only a subset of symtable
which is enough to find a symbol by dw2_lookup_symbol(). As a result, the
objfile->compunit_symtabs, which is the head of a single linked list of
struct compunit_symtab, is not NULL but didn't contain all symtables. It
will not be reinitialized in gdb_get_line_number() by "dis -rl" because
!objfile_has_full_symbols(objfile) check will fail, so it cannot display
the proper code line number data.

Since objfile_has_full_symbols(objfile) check cannot ensure all symbols
been expanded, this patch add a new member as a flag for struct objfile
to record if all symbols have been expanded. The flag will be set only ofter
expand_all_symtabs been called.

Signed-off-by: Tao Liu <[email protected]>
sugarfillet pushed a commit to sugarfillet/crash that referenced this issue Dec 13, 2023
The patch introduces per-cpu overflow stacks for RISCV64 to let
"bt" do backtrace on it and the 'help -m' command dispalys the
addresss of each per-cpu overflow stack.

TEST: a lkdtm DIRECT EXHAUST_STACK vmcore

```
crash> bt
PID: 1        TASK: ff600000000d8000  CPU: 1    COMMAND: "sh"
 #0 [ff6000001fc501c0] riscv_crash_save_regs at ffffffff8000a1dc
 crash-utility#1 [ff6000001fc50320] panic at ffffffff808773ec
 crash-utility#2 [ff6000001fc50380] walk_stackframe at ffffffff800056da
     PC: ffffffff80876a34  [memset+96]
     RA: ffffffff80563dc0  [recursive_loop+68]
     SP: ff2000000000fd50  CAUSE: 000000000000000f
epc : ffffffff80876a34 ra : ffffffff80563dc0 sp : ff2000000000fd50
 gp : ffffffff81515d38 tp : 0000000000000000 t0 : ff2000000000fd58
 t1 : ff600000000d88c8 t2 : 6143203a6d74646b s0 : ff20000000010190
 s1 : 0000000000000012 a0 : ff2000000000fd58 a1 : 1212121212121212
 a2 : 0000000000000400 a3 : ff20000000010158 a4 : 0000000000000000
 a5 : 725bedba92260900 a6 : 000000000130e0f0 a7 : 0000000000000000
 s2 : ff2000000000fd58 s3 : ffffffff815170d8 s4 : ff20000000013e60
 s5 : 000000000000000e s6 : ff20000000013e60 s7 : 0000000000000000
 s8 : ff60000000861000 s9 : 00007fffc3641694 s10: 00007fffc3641690
 s11: 00005555796ed240 t3 : 0000000000010297 t4 : ffffffff80c17810
 t5 : ffffffff8195e7b8 t6 : ff20000000013b18
 status: 0000000200000120 badaddr: ff2000000000fd58
  cause: 000000000000000f orig_a0: 0000000000000000
--- <OVERFLOW stack> ---
 crash-utility#3 [ff2000000000fd50] memset at ffffffff80876a34
 crash-utility#4 [ff20000000010190] recursive_loop at ffffffff80563e16
 crash-utility#5 [ff200000000105d0] recursive_loop at ffffffff80563e16
 < recursive_loop ...>
 crash-utility#16 [ff20000000013490] recursive_loop at ffffffff80563e16
 crash-utility#17 [ff200000000138d0] recursive_loop at ffffffff80563e16
 crash-utility#18 [ff20000000013d10] lkdtm_EXHAUST_STACK at ffffffff8088005e
 crash-utility#19 [ff20000000013d30] lkdtm_do_action at ffffffff80563292
 crash-utility#20 [ff20000000013d40] direct_entry at ffffffff80563474
 crash-utility#21 [ff20000000013d70] full_proxy_write at ffffffff8032fb3a
 crash-utility#22 [ff20000000013db0] vfs_write at ffffffff801d6414
 crash-utility#23 [ff20000000013e60] ksys_write at ffffffff801d67b8
 crash-utility#24 [ff20000000013eb0] __riscv_sys_write at ffffffff801d6832
 crash-utility#25 [ff20000000013ec0] do_trap_ecall_u at ffffffff80884a20
crash>

crash> help -m
<snip>
        irq_stack_size: 16384
         irq_stacks[0]: ff20000000000000
         irq_stacks[1]: ff20000000008000
        overflow_stack_size: 4096
         overflow_stacks[0]: ff6000001fa7a510
         overflow_stacks[1]: ff6000001fc4f510
crash>
```
Signed-off-by: Song Shuai <[email protected]>
k-hagio pushed a commit that referenced this issue Jan 11, 2024
The patch introduces per-cpu overflow stacks for RISCV64 to let
"bt" do backtrace on it and the 'help -m' command dispalys the
addresss of each per-cpu overflow stack.

TEST: a lkdtm DIRECT EXHAUST_STACK vmcore

  crash> bt
  PID: 1        TASK: ff600000000d8000  CPU: 1    COMMAND: "sh"
   #0 [ff6000001fc501c0] riscv_crash_save_regs at ffffffff8000a1dc
   #1 [ff6000001fc50320] panic at ffffffff808773ec
   #2 [ff6000001fc50380] walk_stackframe at ffffffff800056da
       PC: ffffffff80876a34  [memset+96]
       RA: ffffffff80563dc0  [recursive_loop+68]
       SP: ff2000000000fd50  CAUSE: 000000000000000f
  epc : ffffffff80876a34 ra : ffffffff80563dc0 sp : ff2000000000fd50
   gp : ffffffff81515d38 tp : 0000000000000000 t0 : ff2000000000fd58
   t1 : ff600000000d88c8 t2 : 6143203a6d74646b s0 : ff20000000010190
   s1 : 0000000000000012 a0 : ff2000000000fd58 a1 : 1212121212121212
   a2 : 0000000000000400 a3 : ff20000000010158 a4 : 0000000000000000
   a5 : 725bedba92260900 a6 : 000000000130e0f0 a7 : 0000000000000000
   s2 : ff2000000000fd58 s3 : ffffffff815170d8 s4 : ff20000000013e60
   s5 : 000000000000000e s6 : ff20000000013e60 s7 : 0000000000000000
   s8 : ff60000000861000 s9 : 00007fffc3641694 s10: 00007fffc3641690
   s11: 00005555796ed240 t3 : 0000000000010297 t4 : ffffffff80c17810
   t5 : ffffffff8195e7b8 t6 : ff20000000013b18
   status: 0000000200000120 badaddr: ff2000000000fd58
    cause: 000000000000000f orig_a0: 0000000000000000
  --- <OVERFLOW stack> ---
   #3 [ff2000000000fd50] memset at ffffffff80876a34
   #4 [ff20000000010190] recursive_loop at ffffffff80563e16
   #5 [ff200000000105d0] recursive_loop at ffffffff80563e16
   < recursive_loop ...>
   #16 [ff20000000013490] recursive_loop at ffffffff80563e16
   #17 [ff200000000138d0] recursive_loop at ffffffff80563e16
   #18 [ff20000000013d10] lkdtm_EXHAUST_STACK at ffffffff8088005e
   #19 [ff20000000013d30] lkdtm_do_action at ffffffff80563292
   #20 [ff20000000013d40] direct_entry at ffffffff80563474
   #21 [ff20000000013d70] full_proxy_write at ffffffff8032fb3a
   #22 [ff20000000013db0] vfs_write at ffffffff801d6414
   #23 [ff20000000013e60] ksys_write at ffffffff801d67b8
   #24 [ff20000000013eb0] __riscv_sys_write at ffffffff801d6832
   #25 [ff20000000013ec0] do_trap_ecall_u at ffffffff80884a20
  crash>

  crash> help -m
  <snip>
          irq_stack_size: 16384
           irq_stacks[0]: ff20000000000000
           irq_stacks[1]: ff20000000008000
          overflow_stack_size: 4096
           overflow_stacks[0]: ff6000001fa7a510
           overflow_stacks[1]: ff6000001fc4f510
  crash>

Signed-off-by: Song Shuai <[email protected]>
liutgnu pushed a commit to liutgnu/crash-preview that referenced this issue Feb 21, 2024
The patch introduces per-cpu overflow stacks for RISCV64 to let
"bt" do backtrace on it and the 'help -m' command dispalys the
addresss of each per-cpu overflow stack.

TEST: a lkdtm DIRECT EXHAUST_STACK vmcore

  crash> bt
  PID: 1        TASK: ff600000000d8000  CPU: 1    COMMAND: "sh"
   #0 [ff6000001fc501c0] riscv_crash_save_regs at ffffffff8000a1dc
   crash-utility#1 [ff6000001fc50320] panic at ffffffff808773ec
   crash-utility#2 [ff6000001fc50380] walk_stackframe at ffffffff800056da
       PC: ffffffff80876a34  [memset+96]
       RA: ffffffff80563dc0  [recursive_loop+68]
       SP: ff2000000000fd50  CAUSE: 000000000000000f
  epc : ffffffff80876a34 ra : ffffffff80563dc0 sp : ff2000000000fd50
   gp : ffffffff81515d38 tp : 0000000000000000 t0 : ff2000000000fd58
   t1 : ff600000000d88c8 t2 : 6143203a6d74646b s0 : ff20000000010190
   s1 : 0000000000000012 a0 : ff2000000000fd58 a1 : 1212121212121212
   a2 : 0000000000000400 a3 : ff20000000010158 a4 : 0000000000000000
   a5 : 725bedba92260900 a6 : 000000000130e0f0 a7 : 0000000000000000
   s2 : ff2000000000fd58 s3 : ffffffff815170d8 s4 : ff20000000013e60
   s5 : 000000000000000e s6 : ff20000000013e60 s7 : 0000000000000000
   s8 : ff60000000861000 s9 : 00007fffc3641694 s10: 00007fffc3641690
   s11: 00005555796ed240 t3 : 0000000000010297 t4 : ffffffff80c17810
   t5 : ffffffff8195e7b8 t6 : ff20000000013b18
   status: 0000000200000120 badaddr: ff2000000000fd58
    cause: 000000000000000f orig_a0: 0000000000000000
  --- <OVERFLOW stack> ---
   crash-utility#3 [ff2000000000fd50] memset at ffffffff80876a34
   crash-utility#4 [ff20000000010190] recursive_loop at ffffffff80563e16
   crash-utility#5 [ff200000000105d0] recursive_loop at ffffffff80563e16
   < recursive_loop ...>
   crash-utility#16 [ff20000000013490] recursive_loop at ffffffff80563e16
   crash-utility#17 [ff200000000138d0] recursive_loop at ffffffff80563e16
   crash-utility#18 [ff20000000013d10] lkdtm_EXHAUST_STACK at ffffffff8088005e
   crash-utility#19 [ff20000000013d30] lkdtm_do_action at ffffffff80563292
   crash-utility#20 [ff20000000013d40] direct_entry at ffffffff80563474
   crash-utility#21 [ff20000000013d70] full_proxy_write at ffffffff8032fb3a
   crash-utility#22 [ff20000000013db0] vfs_write at ffffffff801d6414
   crash-utility#23 [ff20000000013e60] ksys_write at ffffffff801d67b8
   crash-utility#24 [ff20000000013eb0] __riscv_sys_write at ffffffff801d6832
   crash-utility#25 [ff20000000013ec0] do_trap_ecall_u at ffffffff80884a20
  crash>

  crash> help -m
  <snip>
          irq_stack_size: 16384
           irq_stacks[0]: ff20000000000000
           irq_stacks[1]: ff20000000008000
          overflow_stack_size: 4096
           overflow_stacks[0]: ff6000001fa7a510
           overflow_stacks[1]: ff6000001fc4f510
  crash>

Signed-off-by: Song Shuai <[email protected]>
adi-g15-ibm pushed a commit to adi-g15-ibm/crash that referenced this issue Mar 10, 2024
The stack unwinding is for kernel addresses only. If non-kernel address
encountered, it is usually a user space address, or non-address value
like a function call parameter. So stopping stack unwinding at non-kernel
address will decrease the invalid unwind results.

Before:
crash> gdb bt
 #0  0xffffffff816a8f65 in context_switch ...
 crash-utility#1  __schedule () ...
 crash-utility#2  0xffffffff816a94e9 in schedule ...
 crash-utility#3  0xffffffff816a86fd in schedule_hrtimeout_range_clock ...
 crash-utility#4  0xffffffff816a8733 in schedule_hrtimeout_range ...
 crash-utility#5  0xffffffff8124bb7e in ep_poll ...
 crash-utility#6  0xffffffff8124d00d in SYSC_epoll_wait ...
 crash-utility#7  SyS_epoll_wait ...
 crash-utility#8  <signal handler called>
 crash-utility#9  0x00007f0449407923 in ?? ()
 crash-utility#10 0xffff880100000001 in ?? ()
 crash-utility#11 0xffff880169b3c010 in ?? ()
 crash-utility#12 0x0000000000000040 in irq_stack_union ()
 crash-utility#13 0xffff880169b3c058 in ?? ()
 crash-utility#14 0xffff880169b3c048 in ?? ()
 crash-utility#15 0xffff880169b3c050 in ?? ()
 crash-utility#16 0x0000000000000000 in ?? ()

After:
crash> gdb bt
 #0  0xffffffff816a8f65 in context_switch ...
 crash-utility#1  __schedule () ...
 crash-utility#2  0xffffffff816a94e9 in schedule () ...
 crash-utility#3  0xffffffff816a86fd in schedule_hrtimeout_range_clock ...
 crash-utility#4  0xffffffff816a8733 in schedule_hrtimeout_range ...
 crash-utility#5  0xffffffff8124bb7e in ep_poll ...
 crash-utility#6  0xffffffff8124d00d in SYSC_epoll_wait ...
 crash-utility#7  SyS_epoll_wait ...
 crash-utility#8  <signal handler called>
 crash-utility#9  0x00007f0449407923 in ?? ()

Signed-off-by: Tao Liu <ltao(a)redhat.com>
adi-g15-ibm pushed a commit to adi-g15-ibm/crash that referenced this issue Mar 27, 2024
The stack unwinding is for kernel addresses only. If non-kernel address
encountered, it is usually a user space address, or non-address value
like a function call parameter. So stopping stack unwinding at non-kernel
address will decrease the invalid unwind results.

Before:
crash> gdb bt
 #0  0xffffffff816a8f65 in context_switch ...
 crash-utility#1  __schedule () ...
 crash-utility#2  0xffffffff816a94e9 in schedule ...
 crash-utility#3  0xffffffff816a86fd in schedule_hrtimeout_range_clock ...
 crash-utility#4  0xffffffff816a8733 in schedule_hrtimeout_range ...
 crash-utility#5  0xffffffff8124bb7e in ep_poll ...
 crash-utility#6  0xffffffff8124d00d in SYSC_epoll_wait ...
 crash-utility#7  SyS_epoll_wait ...
 crash-utility#8  <signal handler called>
 crash-utility#9  0x00007f0449407923 in ?? ()
 crash-utility#10 0xffff880100000001 in ?? ()
 crash-utility#11 0xffff880169b3c010 in ?? ()
 crash-utility#12 0x0000000000000040 in irq_stack_union ()
 crash-utility#13 0xffff880169b3c058 in ?? ()
 crash-utility#14 0xffff880169b3c048 in ?? ()
 crash-utility#15 0xffff880169b3c050 in ?? ()
 crash-utility#16 0x0000000000000000 in ?? ()

After:
crash> gdb bt
 #0  0xffffffff816a8f65 in context_switch ...
 crash-utility#1  __schedule () ...
 crash-utility#2  0xffffffff816a94e9 in schedule () ...
 crash-utility#3  0xffffffff816a86fd in schedule_hrtimeout_range_clock ...
 crash-utility#4  0xffffffff816a8733 in schedule_hrtimeout_range ...
 crash-utility#5  0xffffffff8124bb7e in ep_poll ...
 crash-utility#6  0xffffffff8124d00d in SYSC_epoll_wait ...
 crash-utility#7  SyS_epoll_wait ...
 crash-utility#8  <signal handler called>
 crash-utility#9  0x00007f0449407923 in ?? ()

Signed-off-by: Tao Liu <[email protected]>
adi-g15-ibm pushed a commit to adi-g15-ibm/crash that referenced this issue Mar 27, 2024
The stack unwinding is for kernel addresses only. If non-kernel address
encountered, it is usually a user space address, or non-address value
like a function call parameter. So stopping stack unwinding at non-kernel
address will decrease the invalid unwind results.

Before:
crash> gdb bt
 #0  0xffffffff816a8f65 in context_switch ...
 crash-utility#1  __schedule () ...
 crash-utility#2  0xffffffff816a94e9 in schedule ...
 crash-utility#3  0xffffffff816a86fd in schedule_hrtimeout_range_clock ...
 crash-utility#4  0xffffffff816a8733 in schedule_hrtimeout_range ...
 crash-utility#5  0xffffffff8124bb7e in ep_poll ...
 crash-utility#6  0xffffffff8124d00d in SYSC_epoll_wait ...
 crash-utility#7  SyS_epoll_wait ...
 crash-utility#8  <signal handler called>
 crash-utility#9  0x00007f0449407923 in ?? ()
 crash-utility#10 0xffff880100000001 in ?? ()
 crash-utility#11 0xffff880169b3c010 in ?? ()
 crash-utility#12 0x0000000000000040 in irq_stack_union ()
 crash-utility#13 0xffff880169b3c058 in ?? ()
 crash-utility#14 0xffff880169b3c048 in ?? ()
 crash-utility#15 0xffff880169b3c050 in ?? ()
 crash-utility#16 0x0000000000000000 in ?? ()

After:
crash> gdb bt
 #0  0xffffffff816a8f65 in context_switch ...
 crash-utility#1  __schedule () ...
 crash-utility#2  0xffffffff816a94e9 in schedule () ...
 crash-utility#3  0xffffffff816a86fd in schedule_hrtimeout_range_clock ...
 crash-utility#4  0xffffffff816a8733 in schedule_hrtimeout_range ...
 crash-utility#5  0xffffffff8124bb7e in ep_poll ...
 crash-utility#6  0xffffffff8124d00d in SYSC_epoll_wait ...
 crash-utility#7  SyS_epoll_wait ...
 crash-utility#8  <signal handler called>
 crash-utility#9  0x00007f0449407923 in ?? ()

Signed-off-by: Tao Liu <[email protected]>
adi-g15-ibm pushed a commit to adi-g15-ibm/crash that referenced this issue Mar 27, 2024
The stack unwinding is for kernel addresses only. If non-kernel address
encountered, it is usually a user space address, or non-address value
like a function call parameter. So stopping stack unwinding at non-kernel
address will decrease the invalid unwind results.

Before:
crash> gdb bt
 #0  0xffffffff816a8f65 in context_switch ...
 crash-utility#1  __schedule () ...
 crash-utility#2  0xffffffff816a94e9 in schedule ...
 crash-utility#3  0xffffffff816a86fd in schedule_hrtimeout_range_clock ...
 crash-utility#4  0xffffffff816a8733 in schedule_hrtimeout_range ...
 crash-utility#5  0xffffffff8124bb7e in ep_poll ...
 crash-utility#6  0xffffffff8124d00d in SYSC_epoll_wait ...
 crash-utility#7  SyS_epoll_wait ...
 crash-utility#8  <signal handler called>
 crash-utility#9  0x00007f0449407923 in ?? ()
 crash-utility#10 0xffff880100000001 in ?? ()
 crash-utility#11 0xffff880169b3c010 in ?? ()
 crash-utility#12 0x0000000000000040 in irq_stack_union ()
 crash-utility#13 0xffff880169b3c058 in ?? ()
 crash-utility#14 0xffff880169b3c048 in ?? ()
 crash-utility#15 0xffff880169b3c050 in ?? ()
 crash-utility#16 0x0000000000000000 in ?? ()

After:
crash> gdb bt
 #0  0xffffffff816a8f65 in context_switch ...
 crash-utility#1  __schedule () ...
 crash-utility#2  0xffffffff816a94e9 in schedule () ...
 crash-utility#3  0xffffffff816a86fd in schedule_hrtimeout_range_clock ...
 crash-utility#4  0xffffffff816a8733 in schedule_hrtimeout_range ...
 crash-utility#5  0xffffffff8124bb7e in ep_poll ...
 crash-utility#6  0xffffffff8124d00d in SYSC_epoll_wait ...
 crash-utility#7  SyS_epoll_wait ...
 crash-utility#8  <signal handler called>
 crash-utility#9  0x00007f0449407923 in ?? ()

Signed-off-by: Tao Liu <[email protected]>
adi-g15-ibm pushed a commit to adi-g15-ibm/crash that referenced this issue Mar 28, 2024
The stack unwinding is for kernel addresses only. If non-kernel address
encountered, it is usually a user space address, or non-address value
like a function call parameter. So stopping stack unwinding at non-kernel
address will decrease the invalid unwind results.

Before:
crash> gdb bt
 #0  0xffffffff816a8f65 in context_switch ...
 crash-utility#1  __schedule () ...
 crash-utility#2  0xffffffff816a94e9 in schedule ...
 crash-utility#3  0xffffffff816a86fd in schedule_hrtimeout_range_clock ...
 crash-utility#4  0xffffffff816a8733 in schedule_hrtimeout_range ...
 crash-utility#5  0xffffffff8124bb7e in ep_poll ...
 crash-utility#6  0xffffffff8124d00d in SYSC_epoll_wait ...
 crash-utility#7  SyS_epoll_wait ...
 crash-utility#8  <signal handler called>
 crash-utility#9  0x00007f0449407923 in ?? ()
 crash-utility#10 0xffff880100000001 in ?? ()
 crash-utility#11 0xffff880169b3c010 in ?? ()
 crash-utility#12 0x0000000000000040 in irq_stack_union ()
 crash-utility#13 0xffff880169b3c058 in ?? ()
 crash-utility#14 0xffff880169b3c048 in ?? ()
 crash-utility#15 0xffff880169b3c050 in ?? ()
 crash-utility#16 0x0000000000000000 in ?? ()

After:
crash> gdb bt
 #0  0xffffffff816a8f65 in context_switch ...
 crash-utility#1  __schedule () ...
 crash-utility#2  0xffffffff816a94e9 in schedule () ...
 crash-utility#3  0xffffffff816a86fd in schedule_hrtimeout_range_clock ...
 crash-utility#4  0xffffffff816a8733 in schedule_hrtimeout_range ...
 crash-utility#5  0xffffffff8124bb7e in ep_poll ...
 crash-utility#6  0xffffffff8124d00d in SYSC_epoll_wait ...
 crash-utility#7  SyS_epoll_wait ...
 crash-utility#8  <signal handler called>
 crash-utility#9  0x00007f0449407923 in ?? ()

Signed-off-by: Tao Liu <[email protected]>
adi-g15-ibm pushed a commit to adi-g15-ibm/crash that referenced this issue Mar 28, 2024
The stack unwinding is for kernel addresses only. If non-kernel address
encountered, it is usually a user space address, or non-address value
like a function call parameter. So stopping stack unwinding at non-kernel
address will decrease the invalid unwind results.

Before:
crash> gdb bt
 #0  0xffffffff816a8f65 in context_switch ...
 crash-utility#1  __schedule () ...
 crash-utility#2  0xffffffff816a94e9 in schedule ...
 crash-utility#3  0xffffffff816a86fd in schedule_hrtimeout_range_clock ...
 crash-utility#4  0xffffffff816a8733 in schedule_hrtimeout_range ...
 crash-utility#5  0xffffffff8124bb7e in ep_poll ...
 crash-utility#6  0xffffffff8124d00d in SYSC_epoll_wait ...
 crash-utility#7  SyS_epoll_wait ...
 crash-utility#8  <signal handler called>
 crash-utility#9  0x00007f0449407923 in ?? ()
 crash-utility#10 0xffff880100000001 in ?? ()
 crash-utility#11 0xffff880169b3c010 in ?? ()
 crash-utility#12 0x0000000000000040 in irq_stack_union ()
 crash-utility#13 0xffff880169b3c058 in ?? ()
 crash-utility#14 0xffff880169b3c048 in ?? ()
 crash-utility#15 0xffff880169b3c050 in ?? ()
 crash-utility#16 0x0000000000000000 in ?? ()

After:
crash> gdb bt
 #0  0xffffffff816a8f65 in context_switch ...
 crash-utility#1  __schedule () ...
 crash-utility#2  0xffffffff816a94e9 in schedule () ...
 crash-utility#3  0xffffffff816a86fd in schedule_hrtimeout_range_clock ...
 crash-utility#4  0xffffffff816a8733 in schedule_hrtimeout_range ...
 crash-utility#5  0xffffffff8124bb7e in ep_poll ...
 crash-utility#6  0xffffffff8124d00d in SYSC_epoll_wait ...
 crash-utility#7  SyS_epoll_wait ...
 crash-utility#8  <signal handler called>
 crash-utility#9  0x00007f0449407923 in ?? ()

Signed-off-by: Tao Liu <[email protected]>
adi-g15-ibm pushed a commit to adi-g15-ibm/crash that referenced this issue Mar 29, 2024
The stack unwinding is for kernel addresses only. If non-kernel address
encountered, it is usually a user space address, or non-address value
like a function call parameter. So stopping stack unwinding at non-kernel
address will decrease the invalid unwind results.

Before:
crash> gdb bt
 #0  0xffffffff816a8f65 in context_switch ...
 crash-utility#1  __schedule () ...
 crash-utility#2  0xffffffff816a94e9 in schedule ...
 crash-utility#3  0xffffffff816a86fd in schedule_hrtimeout_range_clock ...
 crash-utility#4  0xffffffff816a8733 in schedule_hrtimeout_range ...
 crash-utility#5  0xffffffff8124bb7e in ep_poll ...
 crash-utility#6  0xffffffff8124d00d in SYSC_epoll_wait ...
 crash-utility#7  SyS_epoll_wait ...
 crash-utility#8  <signal handler called>
 crash-utility#9  0x00007f0449407923 in ?? ()
 crash-utility#10 0xffff880100000001 in ?? ()
 crash-utility#11 0xffff880169b3c010 in ?? ()
 crash-utility#12 0x0000000000000040 in irq_stack_union ()
 crash-utility#13 0xffff880169b3c058 in ?? ()
 crash-utility#14 0xffff880169b3c048 in ?? ()
 crash-utility#15 0xffff880169b3c050 in ?? ()
 crash-utility#16 0x0000000000000000 in ?? ()

After:
crash> gdb bt
 #0  0xffffffff816a8f65 in context_switch ...
 crash-utility#1  __schedule () ...
 crash-utility#2  0xffffffff816a94e9 in schedule () ...
 crash-utility#3  0xffffffff816a86fd in schedule_hrtimeout_range_clock ...
 crash-utility#4  0xffffffff816a8733 in schedule_hrtimeout_range ...
 crash-utility#5  0xffffffff8124bb7e in ep_poll ...
 crash-utility#6  0xffffffff8124d00d in SYSC_epoll_wait ...
 crash-utility#7  SyS_epoll_wait ...
 crash-utility#8  <signal handler called>
 crash-utility#9  0x00007f0449407923 in ?? ()

Signed-off-by: Tao Liu <[email protected]>
k-hagio pushed a commit that referenced this issue Apr 17, 2024
On x86_64, there are cases where crash cannot handle IRQ exception
frames properly.  For example, with RHEL9.3 kernel, "bt" command fails
with with "WARNING possibly bogus exception frame":

  crash> bt -c 30
  PID: 2898241  TASK: ff4cb0ce0da0c680  CPU: 30   COMMAND: "star-ccm+"
   #0 [fffffe4658d88e58] crash_nmi_callback at ffffffffa00675e8
   #1 [fffffe4658d88e68] nmi_handle at ffffffffa002ebab
  ...
  --- <NMI exception stack> ---
  ...
  #13 [ff5eba269937cf90] __do_softirq at ffffffffa0c6c007
  #14 [ff5eba269937cfe0] __irq_exit_rcu at ffffffffa010ef61
  #15 [ff5eba269937cff0] sysvec_apic_timer_interrupt at ffffffffa0c58ca2
  --- <IRQ stack> ---
      RIP: 0000000000000010  RSP: 0000000000000018  RFLAGS: ff5eba26ddc9f7e8
      RAX: 0000000000000a20  RBX: ff5eba26ddc9f940  RCX: 0000000000001000
      RDX: ffffffb559980000  RSI: ff4cb12d67207400  RDI: ffffffffffffffff
      RBP: 0000000000001000   R8: ff5eba26ddc9f940   R9: ff5eba26ddc9f8af
      R10: 0000000000000003  R11: 0000000000000a20  R12: ff5eba26ddc9f8b0
      R13: 000000283c07f000  R14: ff4cb0f5a29a1c00  R15: 0000000000000001
      ORIG_RAX: ffffffffa07c4e60  CS: 0206  SS: 7000001cf0380001
  bt: WARNING: possibly bogus exception frame

Running "crash" with "--machdep irq_eframe_link=0xffffffffffffffe8"
option (i.e. thus irq_eframe_link = -24) works properly:

  PID: 2898241  TASK: ff4cb0ce0da0c680  CPU: 30   COMMAND: "star-ccm+"
   #0 [fffffe4658d88e58] crash_nmi_callback at ffffffffa00675e8
   #1 [fffffe4658d88e68] nmi_handle at ffffffffa002ebab
  ...
  --- <NMI exception stack> ---
  ...
  #13 [ff5eba269937cf90] __do_softirq at ffffffffa0c6c007
  #14 [ff5eba269937cfe0] __irq_exit_rcu at ffffffffa010ef61
  #15 [ff5eba269937cff0] sysvec_apic_timer_interrupt at ffffffffa0c58ca2
  --- <IRQ stack> ---
  #16 [ff5eba26ddc9f738] asm_sysvec_apic_timer_interrupt at ffffffffa0e00e06
      [exception RIP: alloc_pte.constprop.0+32]
      RIP: ffffffffa07c4e60  RSP: ff5eba26ddc9f7e8  RFLAGS: 00000206
      RAX: ff5eba26ddc9f940  RBX: 0000000000001000  RCX: 0000000000000a20
      RDX: 0000000000001000  RSI: ffffffb559980000  RDI: ff4cb12d67207400
      RBP: ff5eba26ddc9f8b0   R8: ff5eba26ddc9f8af   R9: 0000000000000003
      R10: 0000000000000a20  R11: ff5eba26ddc9f940  R12: 000000283c07f000
      R13: ff4cb0f5a29a1c00  R14: 0000000000000001  R15: ff4cb0f5a29a1bf8
      ORIG_RAX: ffffffffffffffff  CS: 0010  SS: 0018
  #17 [ff5eba26ddc9f830] iommu_v1_map_pages at ffffffffa07c5648
  #18 [ff5eba26ddc9f8f8] __iommu_map at ffffffffa07d7803
  #19 [ff5eba26ddc9f990] iommu_map_sg at ffffffffa07d7b71
  #20 [ff5eba26ddc9f9f0] iommu_dma_map_sg at ffffffffa07ddcc9
  #21 [ff5eba26ddc9fa90] __dma_map_sg_attrs at ffffffffa01b5205
  ...

Some background:

asm_common_interrupt:
      callq  error_entry
      movq   %rax,%rsp
      movq   %rsp,%rdi
      movq   0x78(%rsp),%rsi
      movq   $-0x1,0x78(%rsp)
      call common_interrupt    # rsp pointing to regs

common_interrupt:
      pushq  %r12
      pushq  %rbp
      pushq  %rbx
      [...]
      movq   hardirq_stack_ptr,%r11
      movq   %rsp,(%r11)
      movq   %r11,%rsp
      [...]
      call __common_interrupt  # rip:common_interrupt

So frame_size(rip:common_interrupt) = 32 (3 push + ret).

Hence "machdep->machspec->irq_eframe_link = -32;" (see x86_64_irq_eframe_link_init()).

Now:

asm_sysvec_apic_timer_interrupt:
      pushq  $-0x1
      callq  error_entry
      movq   %rax,%rsp
      movq   %rsp,%rdi
      callq  sysvec_apic_timer_interrupt

sysvec_apic_timer_interrupt:
      pushq  %r12
      pushq  %rbp
      [...]
      movq   hardirq_stack_ptr,%r11
      movq   %rsp,(%r11)
      movq   %r11,%rsp
      [...]
      call __sysvec_apic_timer_interrupt  # rip:sysvec_apic_timer_interrupt

Here frame_size(rip:sysvec_apic_timer_interrupt) = 24 (2 push + ret)

We should also notice that:

rip  = *(hardirq_stack_ptr - 8)
rsp  = *(hardirq_stack_ptr)
regs = rsp - frame_size(rip)

But x86_64_get_framesize() does not work with IRQ handlers (returns 0).
So not many options other than hardcoding the most likely value and
looking around it.  Actually x86_64_irq_eframe_link() was trying -32
(default), and then -40, but not -24.

Signed-off-by: Georges Aureau <[email protected]>
adi-g15-ibm pushed a commit to adi-g15-ibm/crash that referenced this issue May 19, 2024
The stack unwinding is for kernel addresses only. If non-kernel address
encountered, it is usually a user space address, or non-address value
like a function call parameter. So stopping stack unwinding at non-kernel
address will decrease the invalid unwind results.

Before:
crash> gdb bt
 #0  0xffffffff816a8f65 in context_switch ...
 crash-utility#1  __schedule () ...
 crash-utility#2  0xffffffff816a94e9 in schedule ...
 crash-utility#3  0xffffffff816a86fd in schedule_hrtimeout_range_clock ...
 crash-utility#4  0xffffffff816a8733 in schedule_hrtimeout_range ...
 crash-utility#5  0xffffffff8124bb7e in ep_poll ...
 crash-utility#6  0xffffffff8124d00d in SYSC_epoll_wait ...
 crash-utility#7  SyS_epoll_wait ...
 crash-utility#8  <signal handler called>
 crash-utility#9  0x00007f0449407923 in ?? ()
 crash-utility#10 0xffff880100000001 in ?? ()
 crash-utility#11 0xffff880169b3c010 in ?? ()
 crash-utility#12 0x0000000000000040 in irq_stack_union ()
 crash-utility#13 0xffff880169b3c058 in ?? ()
 crash-utility#14 0xffff880169b3c048 in ?? ()
 crash-utility#15 0xffff880169b3c050 in ?? ()
 crash-utility#16 0x0000000000000000 in ?? ()

After:
crash> gdb bt
 #0  0xffffffff816a8f65 in context_switch ...
 crash-utility#1  __schedule () ...
 crash-utility#2  0xffffffff816a94e9 in schedule () ...
 crash-utility#3  0xffffffff816a86fd in schedule_hrtimeout_range_clock ...
 crash-utility#4  0xffffffff816a8733 in schedule_hrtimeout_range ...
 crash-utility#5  0xffffffff8124bb7e in ep_poll ...
 crash-utility#6  0xffffffff8124d00d in SYSC_epoll_wait ...
 crash-utility#7  SyS_epoll_wait ...
 crash-utility#8  <signal handler called>
 crash-utility#9  0x00007f0449407923 in ?? ()

Cc: Sourabh Jain <[email protected]>
Cc: Hari Bathini <[email protected]>
Cc: Mahesh J Salgaonkar <[email protected]>
Cc: Naveen N. Rao <[email protected]>
Cc: Lianbo Jiang <[email protected]>
Cc: HAGIO KAZUHITO(萩尾 一仁) <[email protected]>
Cc: Tao Liu <[email protected]>
Cc: Alexey Makhalov <[email protected]>
Signed-off-by: Tao Liu <[email protected]>
adi-g15-ibm pushed a commit to adi-g15-ibm/crash that referenced this issue Jul 31, 2024
The stack unwinding is for kernel addresses only. If non-kernel address
encountered, it is usually a user space address, or non-address value
like a function call parameter. So stopping stack unwinding at non-kernel
address will decrease the invalid unwind results.

Before:
crash> gdb bt
 #0  0xffffffff816a8f65 in context_switch ...
 crash-utility#1  __schedule () ...
 crash-utility#2  0xffffffff816a94e9 in schedule ...
 crash-utility#3  0xffffffff816a86fd in schedule_hrtimeout_range_clock ...
 crash-utility#4  0xffffffff816a8733 in schedule_hrtimeout_range ...
 crash-utility#5  0xffffffff8124bb7e in ep_poll ...
 crash-utility#6  0xffffffff8124d00d in SYSC_epoll_wait ...
 crash-utility#7  SyS_epoll_wait ...
 crash-utility#8  <signal handler called>
 crash-utility#9  0x00007f0449407923 in ?? ()
 crash-utility#10 0xffff880100000001 in ?? ()
 crash-utility#11 0xffff880169b3c010 in ?? ()
 crash-utility#12 0x0000000000000040 in irq_stack_union ()
 crash-utility#13 0xffff880169b3c058 in ?? ()
 crash-utility#14 0xffff880169b3c048 in ?? ()
 crash-utility#15 0xffff880169b3c050 in ?? ()
 crash-utility#16 0x0000000000000000 in ?? ()

After:
crash> gdb bt
 #0  0xffffffff816a8f65 in context_switch ...
 crash-utility#1  __schedule () ...
 crash-utility#2  0xffffffff816a94e9 in schedule () ...
 crash-utility#3  0xffffffff816a86fd in schedule_hrtimeout_range_clock ...
 crash-utility#4  0xffffffff816a8733 in schedule_hrtimeout_range ...
 crash-utility#5  0xffffffff8124bb7e in ep_poll ...
 crash-utility#6  0xffffffff8124d00d in SYSC_epoll_wait ...
 crash-utility#7  SyS_epoll_wait ...
 crash-utility#8  <signal handler called>

Cc: Sourabh Jain <[email protected]>
Cc: Hari Bathini <[email protected]>
Cc: Mahesh J Salgaonkar <[email protected]>
Cc: Naveen N. Rao <[email protected]>
Cc: Lianbo Jiang <[email protected]>
Cc: HAGIO KAZUHITO(萩尾 一仁) <[email protected]>
Cc: Tao Liu <[email protected]>
Cc: Alexey Makhalov <[email protected]>
Signed-off-by: Tao Liu <[email protected]>
lian-bo pushed a commit that referenced this issue Aug 14, 2024
See the following stack trace:
(gdb) bt
 #0  0x00005635ac2b166b in arm64_unwind_frame (frame=0x7ffdaf35cb70,
     bt=0x7ffdaf35d430) at arm64.c:2821
 #1  arm64_back_trace_cmd (bt=0x7ffdaf35d430) at arm64.c:3306
 #2  0x00005635ac27b108 in back_trace (bt=bt@entry=0x7ffdaf35d430) at
     kernel.c:3239
 #3  0x00005635ac2880ae in cmd_bt () at kernel.c:2863
 #4  0x00005635ac1f16dc in exec_command () at main.c:893
 #5  0x00005635ac1f192a in main_loop () at main.c:840
 #6  0x00005635ac50df81 in captured_main (data=<optimized out>) at main.c:1284
 #7  gdb_main (args=<optimized out>) at main.c:1313
 #8  0x00005635ac50e000 in gdb_main_entry (argc=<optimized out>,
     argv=<optimized out>) at main.c:1338
 #9  0x00005635ac1ea2a5 in main (argc=5, argv=0x7ffdaf35dde8) at main.c:721

The issue may be encountered when thread_union symbol not found in vmlinux
due to compiling optimization.

This patch will try the following 2 methods to get the irq_stack_size
when thread_union symbol unavailable:

1. change the thread_shift when KASAN is enabled and with vmcoreinfo.
   In arm64/include/asm/memory.h:

   #if defined(CONFIG_KASAN_GENERIC) || defined(CONFIG_KASAN_SW_TAGS)
   ...
   #define IRQ_STACK_SIZE               THREAD_SIZE

   Since enabling the KASAN will affect the final value,
   this patch reset IRQ_STACK_SIZE according to the calculation process in
   kernel code.

2. Try getting the value from kernel code disassembly, to get
   THREAD_SHIFT directly from tbnz instruction.

   In arch/arm64/kernel/entry.S:
   .macro kernel_ventry, el:req, ht:req, regsize:req, label:req
   ...
         add     sp, sp, x0
         sub     x0, sp, x0
         tbnz    x0, #THREAD_SHIFT, 0f

   $ gdb vmlinux
   (gdb) disass vectors
   Dump of assembler code for function vectors:
      ...
      0xffff800080010804 <+4>:     add     sp, sp, x0
      0xffff800080010808 <+8>:     sub     x0, sp, x0
      0xffff80008001080c <+12>:    tbnz    w0, #16, 0xffff80008001081c <vectors+28>

Signed-off-by: yeping.zheng <[email protected]>
Improved-by: Tao Liu <[email protected]>
lian-bo pushed a commit that referenced this issue Aug 14, 2024
See the following stack trace:
(gdb) bt
 #0  0x00005635ac2b166b in arm64_unwind_frame (frame=0x7ffdaf35cb70,
     bt=0x7ffdaf35d430) at arm64.c:2821
 #1  arm64_back_trace_cmd (bt=0x7ffdaf35d430) at arm64.c:3306
 #2  0x00005635ac27b108 in back_trace (bt=bt@entry=0x7ffdaf35d430) at
     kernel.c:3239
 #3  0x00005635ac2880ae in cmd_bt () at kernel.c:2863
 #4  0x00005635ac1f16dc in exec_command () at main.c:893
 #5  0x00005635ac1f192a in main_loop () at main.c:840
 #6  0x00005635ac50df81 in captured_main (data=<optimized out>) at main.c:1284
 #7  gdb_main (args=<optimized out>) at main.c:1313
 #8  0x00005635ac50e000 in gdb_main_entry (argc=<optimized out>,
     argv=<optimized out>) at main.c:1338
 #9  0x00005635ac1ea2a5 in main (argc=5, argv=0x7ffdaf35dde8) at main.c:721

The issue may be encountered when thread_union symbol not found in vmlinux
due to compiling optimization.

This patch will try the following 2 methods to get the irq_stack_size
when thread_union symbol unavailable:

1. change the thread_shift when KASAN is enabled and with vmcoreinfo.
   In arm64/include/asm/memory.h:

   #if defined(CONFIG_KASAN_GENERIC) || defined(CONFIG_KASAN_SW_TAGS)
   ...
   #define IRQ_STACK_SIZE               THREAD_SIZE

   Since enabling the KASAN will affect the final value,
   this patch reset IRQ_STACK_SIZE according to the calculation process in
   kernel code.

2. Try getting the value from kernel code disassembly, to get
   THREAD_SHIFT directly from tbnz instruction.

   In arch/arm64/kernel/entry.S:
   .macro kernel_ventry, el:req, ht:req, regsize:req, label:req
   ...
         add     sp, sp, x0
         sub     x0, sp, x0
         tbnz    x0, #THREAD_SHIFT, 0f

   $ gdb vmlinux
   (gdb) disass vectors
   Dump of assembler code for function vectors:
      ...
      0xffff800080010804 <+4>:     add     sp, sp, x0
      0xffff800080010808 <+8>:     sub     x0, sp, x0
      0xffff80008001080c <+12>:    tbnz    w0, #16, 0xffff80008001081c <vectors+28>

Signed-off-by: yeping.zheng <[email protected]>
Improved-by: Tao Liu <[email protected]>
adi-g15-ibm pushed a commit to adi-g15-ibm/crash that referenced this issue Aug 27, 2024
The stack unwinding is for kernel addresses only. If non-kernel address
encountered, it is usually a user space address, or non-address value
like a function call parameter. So stopping stack unwinding at non-kernel
address will decrease the invalid unwind results.

Before:
crash> gdb bt
 #0  0xffffffff816a8f65 in context_switch ...
 crash-utility#1  __schedule () ...
 crash-utility#2  0xffffffff816a94e9 in schedule ...
 crash-utility#3  0xffffffff816a86fd in schedule_hrtimeout_range_clock ...
 crash-utility#4  0xffffffff816a8733 in schedule_hrtimeout_range ...
 crash-utility#5  0xffffffff8124bb7e in ep_poll ...
 crash-utility#6  0xffffffff8124d00d in SYSC_epoll_wait ...
 crash-utility#7  SyS_epoll_wait ...
 crash-utility#8  <signal handler called>
 crash-utility#9  0x00007f0449407923 in ?? ()
 crash-utility#10 0xffff880100000001 in ?? ()
 crash-utility#11 0xffff880169b3c010 in ?? ()
 crash-utility#12 0x0000000000000040 in irq_stack_union ()
 crash-utility#13 0xffff880169b3c058 in ?? ()
 crash-utility#14 0xffff880169b3c048 in ?? ()
 crash-utility#15 0xffff880169b3c050 in ?? ()
 crash-utility#16 0x0000000000000000 in ?? ()

After:
crash> gdb bt
 #0  0xffffffff816a8f65 in context_switch ...
 crash-utility#1  __schedule () ...
 crash-utility#2  0xffffffff816a94e9 in schedule () ...
 crash-utility#3  0xffffffff816a86fd in schedule_hrtimeout_range_clock ...
 crash-utility#4  0xffffffff816a8733 in schedule_hrtimeout_range ...
 crash-utility#5  0xffffffff8124bb7e in ep_poll ...
 crash-utility#6  0xffffffff8124d00d in SYSC_epoll_wait ...
 crash-utility#7  SyS_epoll_wait ...
 crash-utility#8  <signal handler called>

Cc: Sourabh Jain <[email protected]>
Cc: Hari Bathini <[email protected]>
Cc: Mahesh J Salgaonkar <[email protected]>
Cc: Naveen N. Rao <[email protected]>
Cc: Lianbo Jiang <[email protected]>
Cc: HAGIO KAZUHITO(萩尾 一仁) <[email protected]>
Cc: Tao Liu <[email protected]>
Cc: Alexey Makhalov <[email protected]>
Signed-off-by: Tao Liu <[email protected]>
liutgnu added a commit to liutgnu/crash-preview that referenced this issue Dec 5, 2024
…usly

There is an issue that, for kernel modules, "dis -rl" fails to display
modules code line number data after execute "bt" command in crash.

Without the patch:
  crsah> mod -S
  crash> bt
  PID: 1500     TASK: ff2bd8b093524000  CPU: 16   COMMAND: "lpfc_worker_0"
   #0 [ff2c9f725c39f9e0] machine_kexec at ffffffff8e0686d3
   ...snip...
   crash-utility#8 [ff2c9f725c39fcc0] __lpfc_sli_release_iocbq_s4 at ffffffffc0f2f425 [lpfc]
   ...snip...
  crash> dis -rl ffffffffc0f60f82
  0xffffffffc0f60eb0 <lpfc_nlp_get>:      nopl   0x0(%rax,%rax,1) [FTRACE NOP]
  0xffffffffc0f60eb5 <lpfc_nlp_get+5>:    push   %rbp
  0xffffffffc0f60eb6 <lpfc_nlp_get+6>:    push   %rbx
  0xffffffffc0f60eb7 <lpfc_nlp_get+7>:    test   %rdi,%rdi

With the patch:
  crash> mod -S
  crash> bt
  PID: 1500     TASK: ff2bd8b093524000  CPU: 16   COMMAND: "lpfc_worker_0"
   #0 [ff2c9f725c39f9e0] machine_kexec at ffffffff8e0686d3
   ...snip...
   crash-utility#8 [ff2c9f725c39fcc0] __lpfc_sli_release_iocbq_s4 at ffffffffc0f2f425 [lpfc]
   ...snip...
  crash> dis -rl ffffffffc0f60f82
  /usr/src/debug/kernel-4.18.0-425.13.1.el8_7/linux-4.18.0-425.13.1.el8_7.x86_64/drivers/scsi/lpfc/lpfc_hbadisc.c: 6756
  0xffffffffc0f60eb0 <lpfc_nlp_get>:      nopl   0x0(%rax,%rax,1) [FTRACE NOP]
  /usr/src/debug/kernel-4.18.0-425.13.1.el8_7/linux-4.18.0-425.13.1.el8_7.x86_64/drivers/scsi/lpfc/lpfc_hbadisc.c: 6759
  0xffffffffc0f60eb5 <lpfc_nlp_get+5>:    push   %rbp

The root cause is, after kernel module been loaded by mod command, the symtable
is not expanded in gdb side. crash bt or dis command will trigger such an
expansion. However the symtable expansion is different for the 2 commands:

The stack trace of "dis -rl" for symtable expanding:

  #0  0x00000000008d8d9f in add_compunit_symtab_to_objfile ...
  crash-utility#1  0x00000000006d3293 in buildsym_compunit::end_symtab_with_blockvector ...
  crash-utility#2  0x00000000006d336a in buildsym_compunit::end_symtab_from_static_block ...
  crash-utility#3  0x000000000077e8e9 in process_full_comp_unit ...
  crash-utility#4  process_queue ...
  crash-utility#5  dw2_do_instantiate_symtab ...
  crash-utility#6  0x000000000077ed67 in dw2_instantiate_symtab ...
  crash-utility#7  0x000000000077f75e in dw2_expand_all_symtabs ...
  crash-utility#8  0x00000000008f254d in gdb_get_line_number ...
  crash-utility#9  0x00000000008f22af in gdb_command_funnel_1 ...
  crash-utility#10 0x00000000008f2003 in gdb_command_funnel ...
  crash-utility#11 0x00000000005b7f02 in gdb_interface ...
  crash-utility#12 0x00000000005f5bd8 in get_line_number ...
  crash-utility#13 0x000000000059e574 in cmd_dis ...

The stack trace of "bt" for symtable expanding:

  #0  0x00000000008d8d9f in add_compunit_symtab_to_objfile ...
  crash-utility#1  0x00000000006d3293 in buildsym_compunit::end_symtab_with_blockvector ...
  crash-utility#2  0x00000000006d336a in buildsym_compunit::end_symtab_from_static_block ...
  crash-utility#3  0x000000000077e8e9 in process_full_comp_unit ...
  crash-utility#4  process_queue ...
  crash-utility#5  dw2_do_instantiate_symtab ...
  crash-utility#6  0x000000000077ed67 in dw2_instantiate_symtab ...
  crash-utility#7  0x000000000077f8ed in dw2_lookup_symbol ...
  crash-utility#8  0x00000000008e6d03 in lookup_symbol_via_quick_fns ...
  crash-utility#9  0x00000000008e7153 in lookup_symbol_in_objfile ...
  crash-utility#10 0x00000000008e73c6 in lookup_symbol_global_or_static_iterator_cb ...
  crash-utility#11 0x00000000008b99c4 in svr4_iterate_over_objfiles_in_search_order ...
  crash-utility#12 0x00000000008e754e in lookup_global_or_static_symbol ...
  crash-utility#13 0x00000000008e75da in lookup_static_symbol ...
  crash-utility#14 0x00000000008e632c in lookup_symbol_aux ...
  crash-utility#15 0x00000000008e5a7a in lookup_symbol_in_language ...
  crash-utility#16 0x00000000008e5b30 in lookup_symbol ...
  crash-utility#17 0x00000000008f2a4a in gdb_get_datatype ...
  crash-utility#18 0x00000000008f22c0 in gdb_command_funnel_1 ...
  crash-utility#19 0x00000000008f2003 in gdb_command_funnel ...
  crash-utility#20 0x00000000005b7f02 in gdb_interface ...
  crash-utility#21 0x00000000005f8a9f in datatype_info ...
  crash-utility#22 0x0000000000599947 in cpu_map_size ...
  crash-utility#23 0x00000000005a975d in get_cpus_online ...
  crash-utility#24 0x0000000000637a8b in diskdump_get_prstatus_percpu ...
  crash-utility#25 0x000000000062f0e4 in get_netdump_regs_x86_64 ...
  crash-utility#26 0x000000000059fe68 in back_trace ...
  crash-utility#27 0x00000000005ab1cb in cmd_bt ...

For the stacktrace of "dis -rl", it calls dw2_expand_all_symtabs() to expand
all symtable of the objfile, or "*.ko.debug" in our case. However for
the stacktrace of "bt", it doesn't expand all, but only a subset of symtable
which is enough to find a symbol by dw2_lookup_symbol(). As a result, the
objfile->compunit_symtabs, which is the head of a single linked list of
struct compunit_symtab, is not NULL but didn't contain all symtables. It
will not be reinitialized in gdb_get_line_number() by "dis -rl" because
!objfile_has_full_symbols(objfile) check will fail, so it cannot display
the proper code line number data.

Since objfile_has_full_symbols(objfile) check cannot ensure all symbols
been expanded, this patch add a new member as a flag for struct objfile
to record if all symbols have been expanded. The flag will be set only ofter
expand_all_symtabs been called.

Signed-off-by: Tao Liu <[email protected]>
liutgnu pushed a commit to liutgnu/crash-preview that referenced this issue Dec 5, 2024
The patch introduces per-cpu overflow stacks for RISCV64 to let
"bt" do backtrace on it and the 'help -m' command dispalys the
addresss of each per-cpu overflow stack.

TEST: a lkdtm DIRECT EXHAUST_STACK vmcore

  crash> bt
  PID: 1        TASK: ff600000000d8000  CPU: 1    COMMAND: "sh"
   #0 [ff6000001fc501c0] riscv_crash_save_regs at ffffffff8000a1dc
   crash-utility#1 [ff6000001fc50320] panic at ffffffff808773ec
   crash-utility#2 [ff6000001fc50380] walk_stackframe at ffffffff800056da
       PC: ffffffff80876a34  [memset+96]
       RA: ffffffff80563dc0  [recursive_loop+68]
       SP: ff2000000000fd50  CAUSE: 000000000000000f
  epc : ffffffff80876a34 ra : ffffffff80563dc0 sp : ff2000000000fd50
   gp : ffffffff81515d38 tp : 0000000000000000 t0 : ff2000000000fd58
   t1 : ff600000000d88c8 t2 : 6143203a6d74646b s0 : ff20000000010190
   s1 : 0000000000000012 a0 : ff2000000000fd58 a1 : 1212121212121212
   a2 : 0000000000000400 a3 : ff20000000010158 a4 : 0000000000000000
   a5 : 725bedba92260900 a6 : 000000000130e0f0 a7 : 0000000000000000
   s2 : ff2000000000fd58 s3 : ffffffff815170d8 s4 : ff20000000013e60
   s5 : 000000000000000e s6 : ff20000000013e60 s7 : 0000000000000000
   s8 : ff60000000861000 s9 : 00007fffc3641694 s10: 00007fffc3641690
   s11: 00005555796ed240 t3 : 0000000000010297 t4 : ffffffff80c17810
   t5 : ffffffff8195e7b8 t6 : ff20000000013b18
   status: 0000000200000120 badaddr: ff2000000000fd58
    cause: 000000000000000f orig_a0: 0000000000000000
  --- <OVERFLOW stack> ---
   crash-utility#3 [ff2000000000fd50] memset at ffffffff80876a34
   crash-utility#4 [ff20000000010190] recursive_loop at ffffffff80563e16
   crash-utility#5 [ff200000000105d0] recursive_loop at ffffffff80563e16
   < recursive_loop ...>
   crash-utility#16 [ff20000000013490] recursive_loop at ffffffff80563e16
   crash-utility#17 [ff200000000138d0] recursive_loop at ffffffff80563e16
   crash-utility#18 [ff20000000013d10] lkdtm_EXHAUST_STACK at ffffffff8088005e
   crash-utility#19 [ff20000000013d30] lkdtm_do_action at ffffffff80563292
   crash-utility#20 [ff20000000013d40] direct_entry at ffffffff80563474
   crash-utility#21 [ff20000000013d70] full_proxy_write at ffffffff8032fb3a
   crash-utility#22 [ff20000000013db0] vfs_write at ffffffff801d6414
   crash-utility#23 [ff20000000013e60] ksys_write at ffffffff801d67b8
   crash-utility#24 [ff20000000013eb0] __riscv_sys_write at ffffffff801d6832
   crash-utility#25 [ff20000000013ec0] do_trap_ecall_u at ffffffff80884a20
  crash>

  crash> help -m
  <snip>
          irq_stack_size: 16384
           irq_stacks[0]: ff20000000000000
           irq_stacks[1]: ff20000000008000
          overflow_stack_size: 4096
           overflow_stacks[0]: ff6000001fa7a510
           overflow_stacks[1]: ff6000001fc4f510
  crash>

Signed-off-by: Song Shuai <[email protected]>
liutgnu pushed a commit to liutgnu/crash-preview that referenced this issue Dec 5, 2024
On x86_64, there are cases where crash cannot handle IRQ exception
frames properly.  For example, with RHEL9.3 kernel, "bt" command fails
with with "WARNING possibly bogus exception frame":

  crash> bt -c 30
  PID: 2898241  TASK: ff4cb0ce0da0c680  CPU: 30   COMMAND: "star-ccm+"
   #0 [fffffe4658d88e58] crash_nmi_callback at ffffffffa00675e8
   crash-utility#1 [fffffe4658d88e68] nmi_handle at ffffffffa002ebab
  ...
  --- <NMI exception stack> ---
  ...
  crash-utility#13 [ff5eba269937cf90] __do_softirq at ffffffffa0c6c007
  crash-utility#14 [ff5eba269937cfe0] __irq_exit_rcu at ffffffffa010ef61
  crash-utility#15 [ff5eba269937cff0] sysvec_apic_timer_interrupt at ffffffffa0c58ca2
  --- <IRQ stack> ---
      RIP: 0000000000000010  RSP: 0000000000000018  RFLAGS: ff5eba26ddc9f7e8
      RAX: 0000000000000a20  RBX: ff5eba26ddc9f940  RCX: 0000000000001000
      RDX: ffffffb559980000  RSI: ff4cb12d67207400  RDI: ffffffffffffffff
      RBP: 0000000000001000   R8: ff5eba26ddc9f940   R9: ff5eba26ddc9f8af
      R10: 0000000000000003  R11: 0000000000000a20  R12: ff5eba26ddc9f8b0
      R13: 000000283c07f000  R14: ff4cb0f5a29a1c00  R15: 0000000000000001
      ORIG_RAX: ffffffffa07c4e60  CS: 0206  SS: 7000001cf0380001
  bt: WARNING: possibly bogus exception frame

Running "crash" with "--machdep irq_eframe_link=0xffffffffffffffe8"
option (i.e. thus irq_eframe_link = -24) works properly:

  PID: 2898241  TASK: ff4cb0ce0da0c680  CPU: 30   COMMAND: "star-ccm+"
   #0 [fffffe4658d88e58] crash_nmi_callback at ffffffffa00675e8
   crash-utility#1 [fffffe4658d88e68] nmi_handle at ffffffffa002ebab
  ...
  --- <NMI exception stack> ---
  ...
  crash-utility#13 [ff5eba269937cf90] __do_softirq at ffffffffa0c6c007
  crash-utility#14 [ff5eba269937cfe0] __irq_exit_rcu at ffffffffa010ef61
  crash-utility#15 [ff5eba269937cff0] sysvec_apic_timer_interrupt at ffffffffa0c58ca2
  --- <IRQ stack> ---
  crash-utility#16 [ff5eba26ddc9f738] asm_sysvec_apic_timer_interrupt at ffffffffa0e00e06
      [exception RIP: alloc_pte.constprop.0+32]
      RIP: ffffffffa07c4e60  RSP: ff5eba26ddc9f7e8  RFLAGS: 00000206
      RAX: ff5eba26ddc9f940  RBX: 0000000000001000  RCX: 0000000000000a20
      RDX: 0000000000001000  RSI: ffffffb559980000  RDI: ff4cb12d67207400
      RBP: ff5eba26ddc9f8b0   R8: ff5eba26ddc9f8af   R9: 0000000000000003
      R10: 0000000000000a20  R11: ff5eba26ddc9f940  R12: 000000283c07f000
      R13: ff4cb0f5a29a1c00  R14: 0000000000000001  R15: ff4cb0f5a29a1bf8
      ORIG_RAX: ffffffffffffffff  CS: 0010  SS: 0018
  crash-utility#17 [ff5eba26ddc9f830] iommu_v1_map_pages at ffffffffa07c5648
  crash-utility#18 [ff5eba26ddc9f8f8] __iommu_map at ffffffffa07d7803
  crash-utility#19 [ff5eba26ddc9f990] iommu_map_sg at ffffffffa07d7b71
  crash-utility#20 [ff5eba26ddc9f9f0] iommu_dma_map_sg at ffffffffa07ddcc9
  crash-utility#21 [ff5eba26ddc9fa90] __dma_map_sg_attrs at ffffffffa01b5205
  ...

Some background:

asm_common_interrupt:
      callq  error_entry
      movq   %rax,%rsp
      movq   %rsp,%rdi
      movq   0x78(%rsp),%rsi
      movq   $-0x1,0x78(%rsp)
      call common_interrupt    # rsp pointing to regs

common_interrupt:
      pushq  %r12
      pushq  %rbp
      pushq  %rbx
      [...]
      movq   hardirq_stack_ptr,%r11
      movq   %rsp,(%r11)
      movq   %r11,%rsp
      [...]
      call __common_interrupt  # rip:common_interrupt

So frame_size(rip:common_interrupt) = 32 (3 push + ret).

Hence "machdep->machspec->irq_eframe_link = -32;" (see x86_64_irq_eframe_link_init()).

Now:

asm_sysvec_apic_timer_interrupt:
      pushq  $-0x1
      callq  error_entry
      movq   %rax,%rsp
      movq   %rsp,%rdi
      callq  sysvec_apic_timer_interrupt

sysvec_apic_timer_interrupt:
      pushq  %r12
      pushq  %rbp
      [...]
      movq   hardirq_stack_ptr,%r11
      movq   %rsp,(%r11)
      movq   %r11,%rsp
      [...]
      call __sysvec_apic_timer_interrupt  # rip:sysvec_apic_timer_interrupt

Here frame_size(rip:sysvec_apic_timer_interrupt) = 24 (2 push + ret)

We should also notice that:

rip  = *(hardirq_stack_ptr - 8)
rsp  = *(hardirq_stack_ptr)
regs = rsp - frame_size(rip)

But x86_64_get_framesize() does not work with IRQ handlers (returns 0).
So not many options other than hardcoding the most likely value and
looking around it.  Actually x86_64_irq_eframe_link() was trying -32
(default), and then -40, but not -24.

Signed-off-by: Georges Aureau <[email protected]>
liutgnu added a commit to liutgnu/crash-preview that referenced this issue Dec 5, 2024
See the following stack trace:
(gdb) bt
 #0  0x00005635ac2b166b in arm64_unwind_frame (frame=0x7ffdaf35cb70,
     bt=0x7ffdaf35d430) at arm64.c:2821
 crash-utility#1  arm64_back_trace_cmd (bt=0x7ffdaf35d430) at arm64.c:3306
 crash-utility#2  0x00005635ac27b108 in back_trace (bt=bt@entry=0x7ffdaf35d430) at
     kernel.c:3239
 crash-utility#3  0x00005635ac2880ae in cmd_bt () at kernel.c:2863
 crash-utility#4  0x00005635ac1f16dc in exec_command () at main.c:893
 crash-utility#5  0x00005635ac1f192a in main_loop () at main.c:840
 crash-utility#6  0x00005635ac50df81 in captured_main (data=<optimized out>) at main.c:1284
 crash-utility#7  gdb_main (args=<optimized out>) at main.c:1313
 crash-utility#8  0x00005635ac50e000 in gdb_main_entry (argc=<optimized out>,
     argv=<optimized out>) at main.c:1338
 crash-utility#9  0x00005635ac1ea2a5 in main (argc=5, argv=0x7ffdaf35dde8) at main.c:721

The issue may be encountered when thread_union symbol not found in vmlinux
due to compiling optimization.

This patch will try the following 2 methods to get the irq_stack_size
when thread_union symbol unavailable:

1. change the thread_shift when KASAN is enabled and with vmcoreinfo.
   In arm64/include/asm/memory.h:

   #if defined(CONFIG_KASAN_GENERIC) || defined(CONFIG_KASAN_SW_TAGS)
   ...
   #define IRQ_STACK_SIZE               THREAD_SIZE

   Since enabling the KASAN will affect the final value,
   this patch reset IRQ_STACK_SIZE according to the calculation process in
   kernel code.

2. Try getting the value from kernel code disassembly, to get
   THREAD_SHIFT directly from tbnz instruction.

   In arch/arm64/kernel/entry.S:
   .macro kernel_ventry, el:req, ht:req, regsize:req, label:req
   ...
         add     sp, sp, x0
         sub     x0, sp, x0
         tbnz    x0, #THREAD_SHIFT, 0f

   $ gdb vmlinux
   (gdb) disass vectors
   Dump of assembler code for function vectors:
      ...
      0xffff800080010804 <+4>:     add     sp, sp, x0
      0xffff800080010808 <+8>:     sub     x0, sp, x0
      0xffff80008001080c <+12>:    tbnz    w0, crash-utility#16, 0xffff80008001081c <vectors+28>

Signed-off-by: yeping.zheng <[email protected]>
Improved-by: Tao Liu <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant