Re: [PATCH 1/2] Revert "Fix segfault in arm64_is_kernel_exception_frame() when corrupt stack pointer address is given"

[lijiang <lijiang@xxxxxxxxxx>]

On Mon, Jun 12, 2023 at 7:24 PM Daisuke Hatayama (Fujitsu) <d.hatayama@xxxxxxxxxxx> wrote:

> Thank you for pointing out this issue, HATAYAMA.
>
> Anyway, I did not reproduce the above issue. Seems it can not always be reproduced.
>
> # ./crash /home/vmlinux /var/crash/127.0.0.1-2023-06-09-05\:20\:38/vmcore -s
> WARNING: cpu 2: invalid NT_PRSTATUS note (n_type != NT_PRSTATUS)
> WARNING: cpu 1: cannot find NT_PRSTATUS note
> WARNING: cpu 2: cannot find NT_PRSTATUS note
> crash> ps insmod
>       PID    PPID  CPU       TASK        ST  %MEM      VSZ      RSS  COMM
>      1684    1683   0  ffff06738f1cdd00  ZO   0.0        0        0  insmod
> crash> bt 1684
> PID: 1684     TASK: ffff06738f1cdd00  CPU: 0    COMMAND: "insmod"
> (no stack)
> crash>

The problematic case is the active tasks running in user mode at the
moment of kernel panic. In most cases, it's enough to prepare some
programs that running in infinite loop just like:

    # while : ; do continue ; done &
    [3] 3295

Just in case, note that this issue is different from the one of
corrupt mapping of NT_PRSTATUS notes. You don't need to use the

Thank you for the explanation,  HATAYAMA. It's true, they are different issues, that is why it can not always be reproduced.

crash> ps insmod
      PID    PPID  CPU       TASK        ST  %MEM      VSZ      RSS  COMM
     1696    1695   2  ffff2e420cf5a900  RU   0.0     7168     3840  insmod
crash> bt 1696
PID: 1696     TASK: ffff2e420cf5a900  CPU: 2    COMMAND: "insmod"
 #0 [ffff800013eefae0] __switch_to at ffffc029d3cc9d24
 #1 [ffff800013eefb10] __schedule at ffffc029d475c1fc
 #2 [ffff800013eefba0] preempt_schedule_common at ffffc029d475cd7c
 #3 [ffff800013eefbb0] _cond_resched at ffffc029d475cdc8
 #4 [ffff800013eefbc0] down_read at ffffc029d475fdbc
 #5 [ffff800013eefbe0] blocking_notifier_call_chain at ffffc029d3d66024
 #6 [ffff800013eefc10] do_init_module at ffffc029d3e1040c
 #7 [ffff800013eefc40] load_module at ffffc029d3e12948
 #8 [ffff800013eefda0] __se_sys_finit_module at ffffc029d3e12ebc
 #9 [ffff800013eefe60] __arm64_sys_finit_module at ffffc029d3e12f7c
#10 [ffff800013eefe80] do_el0_svc at ffffc029d3cd9300
#11 [ffff800013eefeb0] el0_sync_handler at ffffc029d3cc9374
#12 [ffff800013eefff0] el0_sync at ffffc029d3cc2b7c
     PC: 0000ffff9b7637e4   LR: 0000aaaabe6b3e48   SP: 0000ffffc6f33810
    X29: 0000ffffc6f33810  X28: 0000000000000000  X27: 0000000000000000
    X26: 0000000000000002  X25: 0000000000000000  X24: 0000ffffc6f338e8
    X23: 0000aaaad7da1840  X22: 0000000000000000  X21: 0000000000000000
    X20: 0000aaaabe6bd520  X19: 0000aaaad7da1860  X18: 0000000000000000
    X17: 0000ffff9b7637c0  X16: 0000aaaabe6dfd98  X15: 0000000000000070
    X14: 0000000000000002  X13: 000000000000270f  X12: 0000000000000000
    X11: 0000000000000000  X10: 0000000000000000   X9: 0000aaaad7da1960
     X8: 0000000000000111   X7: 0000000000000001   X6: 0000000000000001
     X5: 0000000000000db1   X4: 0000000000000000   X3: 0000000000000003
     X2: 0000000000000000   X1: 0000aaaabe6bd520   X0: 0000000000000003
    ORIG_X0: 0000000000000003  SYSCALLNO: 111  PSTATE: 40001000

reproduction steps I shared. It's enough to prepare the above busy
loop process in advance, make the kernel panic and then use bt command
for the busy loop process.

You are right. I have reproduced the current problem with an infinite loop process.

 crash> ps t

      PID    PPID  CPU       TASK        ST  %MEM      VSZ      RSS  COMM
>    8419    1896   2  ffff08aa9360ff00  RU   0.0     2432     1216  t
crash> bt 8419
PID: 8419     TASK: ffff08aa9360ff00  CPU: 2    COMMAND: "t"
bt: invalid stack pointer is given

I have no other issues about it.

Thanks.

Lianbo

Thanks.
HATAYAMA, Daisuke

--
Crash-utility mailing list
Crash-utility@xxxxxxxxxx
https://listman.redhat.com/mailman/listinfo/crash-utility
Contribution Guidelines: https://github.com/crash-utility/crash/wiki