[Crash-utility] Re: [PATCH] Fix for "bt pid" command not printing enough stack trace

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