On 2023/06/14 15:32, lijiang 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).
ok, applied the patches.
https://github.com/crash-utility/crash/commit/6c8cd9b5dcf48221e5f75fc5850bb4719d77acce
Thanks,
Kazu
--
Crash-utility mailing list
Crash-utility@xxxxxxxxxx
https://listman.redhat.com/mailman/listinfo/crash-utility
Contribution Guidelines: https://github.com/crash-utility/crash/wiki
