<div dir="ltr"><div dir="ltr">On Mon, Jun 12, 2023 at 7:44 PM Daisuke Hatayama (Fujitsu) <<a href="mailto:d.hatayama@fujitsu.com">d.hatayama@fujitsu.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">> I still have one question: Why does this one only need to be fixed,<br>
> but the others are not needed(it won't be out of range)? The<br>
> STACK_OFFSET_TYPE() is invoked multiple times in arm64.c, and<br>
> similar calls can be seen on other arches(grep -nr "GET_STACK_ULONG"<br>
> *.c or grep -nr "GET_STACK_DATA" *.c).<br>
><br>
> # grep -nr "STACK_OFFSET_TYPE" *.c<br>
> arm64.c:2384:        regs = (struct arm64_pt_regs *)&bt->stackbuf[(ulong)(STACK_OFFSET_TYPE(stkptr))];<br>
> arm64.c:2821: ptregs = (struct arm64_pt_regs *)&bt->stackbuf[(ulong)(STACK_OFFSET_TYPE(orig_sp))];<br>
> arm64.c:3476: base = (ulong *)&bt->stackbuf[(ulong)(STACK_OFFSET_TYPE(bt->stackbase))];<br>
> arm64.c:3478: start = (ulong *)&bt->stackbuf[(ulong)(STACK_OFFSET_TYPE(bt->stacktop))];<br>
> arm64.c:3481: start = (ulong *)&bt->stackbuf[(ulong)(STACK_OFFSET_TYPE(frame->fp))];<br>
> arm64.c:3483: start = (ulong *)&bt->stackbuf[(ulong)(STACK_OFFSET_TYPE(bt->stacktop))];<br>
> arm64.c:3801: &bt->stackbuf[(ulong)(STACK_OFFSET_TYPE(sp))];<br>
> arm64.c:3822:       &bt->stackbuf[(ulong)(STACK_OFFSET_TYPE(pt_regs))];<br>
> x86.c:1075: if (STACK_OFFSET_TYPE(ep->eframe_addr) > STACKSIZE())<br>
> [root@hpe-apollo-cn99xx-13-vm-01 crash]# grep -nr "STACK_OFFSET_TYPE" *.h<br>
> defs.h:977:#define STACK_OFFSET_TYPE(OFF) \<br>
> defs.h:985: *((ulong *)((char *)(&bt->stackbuf[(ulong)(STACK_OFFSET_TYPE(OFF))])))<br>
> defs.h:988:    (void *)(&bt->stackbuf[(ulong)STACK_OFFSET_TYPE(OFF)]), (size_t)(SZ))<br>
<br>
As explained in the patch descriptions, STACK_OFFSET_TYPE() is used in<br>
each occurrences in the different context. To check if each is<br>
implemented correctly needs to understand what each does. I don't know<br>
whether there is another place where returned value of<br>
STACK_OFFSET_TYPE() is handled incorrectly. My quick look didn't find<br></blockquote><div><br></div><div>Got it. Thanks.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
the part that might touch invalid range of memory. The reason why I'm<br>
trying to fix the arm64_is_kernel_exception_frame() is I found the<br>
issue there.<br>
<br></blockquote><div><br></div><div>So far I haven't observed this issue on my side. As you mentioned, the corrupt stack pointer address may be related to any kernel bugs or hardware issues. At least the real reason for the corrupt stack pointer address is not very clear, so how about adding some debugging information? Just an idea. HATAYAMA and Kazu.</div><div><br></div><div>+       if (stkptr > STACKSIZE() && !INSTACK(stkptr, bt)) {</div><div>+               if (CRASHDEBUG(1))<br><a class="gmail_plusreply" id="plusReplyChip-1">+</a>                        error(WARNING, "The stkptr(0x%lx) is an address outside the range of kernel stack.\n", stkptr);<br>+               return FALSE;</div><div>+       }<br>+</div><div><br></div><div><br></div><div>Thanks.</div><div>Lianbo</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Thanks.<br>
HATAYAMA, Daisuke<br>
<br>
<br>
</blockquote></div></div>