On 2024/01/15 14:13, HAGIO KAZUHITO(萩尾 一仁) wrote:
> On 2024/01/12 19:46, Lianbo Jiang wrote:
>
>>> Could I have a few additional information?:
>> Sure.
>>> - What is the kernel version? (e.g. 5.14.0-362.8.1.el9_3.x86_64)
>> I observed the current issue on the kernel 5.14.0-283.rt14.283.el9.x86_64.
>>> - What happens with the following patch?
>>
>> The following changes can also work in this case.
>
> Good, thanks for trying.
>
>>
>> Do you prefer adding an ORC check or a similar check in x86_64_function_called_by()? Or both?
>
> x86_64_function_called_by() is for looking for the called function and
> used in other places. The issue is that the caller check itself does
> not work correctly on some kernels, I think there is no need to change
> it this time.
>
> With ORC data, I think there is no need to check a caller in almost
> cases, so I would like to skip the check:
>
> --- a/x86_64.c
> +++ b/x86_64.c
> @@ -3342,6 +3342,13 @@ x86_64_print_stack_entry(struct bt_info *bt, FILE
> *ofp, int level,
>
> bt->call_target = name;
>
> + /*
> + * The caller check below does not work correctly for some
> + * kernels, so skip it if ORC unwidner is available.
> + */
> + if (machdep->flags & ORC)
> + return result;
> +
> if (is_direct_call_target(bt)) {
> if (CRASHDEBUG(2))
> fprintf(ofp, "< enable BT_CHECK_CALLER for %s >\n",
>
> Could I have the output of "bt 493113" after "set debug 2" with this?
> (An attached text file is better for logs.)
>
> and I will test this with various vmcores on hand..
I've tested the above patch with Linux 4.x to 6.x vmcores and several
RHEL8 and RHEL9 vmcores, no regression was found.
I also found some vmcores having a short backtrace, and these are fixed
by the patch above:
PID: 99 TASK: ffff9c50c9944d40 CPU: 1 COMMAND: "hwrng"
#0 [ffffae7ac042bdf8] __schedule at ffffffffb40ba251
#1 [ffffae7ac042be60] schedule at ffffffffb40ba70a
#2 [ffffae7ac042be78] schedule_timeout at ffffffffb40c0298
+ #3 [ffffae7ac042bec8] hwrng_fillfn at ffffffffb3bf4234
+ #4 [ffffae7ac042bef8] kthread at ffffffffb354077f
+ #5 [ffffae7ac042bf30] ret_from_fork at ffffffffb343b0ed
+ #6 [ffffae7ac042bf50] ret_from_fork_asm at ffffffffb3402fdb
Thanks,
Kazu
--
Crash-utility mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxxxxxx
https://${domain_name}/admin/lists/devel.lists.crash-utility.osci.io/
Contribution Guidelines: https://github.com/crash-utility/crash/wiki
