On 1/15/24 13: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:
Fine to me, let's go with this one, Kazu.
--- 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.)
Sure. Please check the crash_bt_493113.txt.
and I will test this with various vmcores on hand..
This needs to construct a similar case, it exactly happens on the point
such as schedule_timeout() or schedule().
Thanks
Lianbo
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
