On Wed, Jun 14, 2023 at 1:38 PM HAGIO KAZUHITO(萩尾 一仁) <k-hagio-ab@xxxxxxx> 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@xxxxxxxxxx https://listman.redhat.com/mailman/listinfo/crash-utility Contribution Guidelines: https://github.com/crash-utility/crash/wiki
