On Wed, Jun 14, 2023 at 1:38 PM HAGIO KAZUHITO(萩尾 一仁) <k-hagio...@nec.com>
wrote:
>
> On 2023/06/13 19:25, lijiang wrote:
> >> the part that might touch invalid range of memory. The reason why I'm
> >> trying to fix the arm64_is_kernel_exception_frame() is I found the
> >> issue there.
> >>
> >>
> > 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.
> >
> > + if (stkptr > STACKSIZE() && !INSTACK(stkptr, bt)) {
> > + if (CRASHDEBUG(1))
> > + error(WARNING, "The stkptr(0x%lx) is an address
> > outside the range of kernel stack.\n", stkptr);
> > + return FALSE;
> > + }
> > +
>
> I cannot test it, but I'm ok with printing a warning with CRASHDEBUG().
> I like a shorter one like:
> "stkptr: %lx is outside the kernel stack range\n"
>
>
Thanks, Kazu. Fine to me, for the patch series: Ack (with the above change).
Lianbo
--
Crash-utility mailing list
Crash-utility@redhat.com
https://listman.redhat.com/mailman/listinfo/crash-utility
Contribution Guidelines: https://github.com/crash-utility/crash/wiki
