[Crash-utility] Fix in bt for ARM64

[Dave Anderson]

----- Original Message -----
> 
> 
> Hi Dave
> 
> 
> 
> I found an ARM64 problem for bt when a function belongs to a module.
> 
> 
> 
> Printout before fix given below:
> 
> #16 [ffffffc0be96f8d0] __this_module at ffffffbffc15a2f8 [wlan]
> #17 [ffffffc0be96f9b0] __this_module at ffffffbffc161b18 [wlan]
> #18 [ffffffc0be96f9c0] __this_module at ffffffbffc16033c [wlan]
> #19 [ffffffc0be96fa10] __this_module at ffffffbffc1630f8 [wlan]
> #20 [ffffffc0be96fab0] __this_module at ffffffbffc156ff8 [wlan]
> #21 [ffffffc0be96faf0] __this_module at ffffffbffc15aa58 [wlan]
> #22 [ffffffc0be96fb20] __this_module at ffffffbffc15bfc8 [wlan]
> #23 [ffffffc0be96fb60] __this_module at ffffffbffc115fac [wlan]
> #24 [ffffffc0be96fb90] tasklet_action at ffffffc000223738
> #25 [ffffffc0be96fbb0] __do_softirq at ffffffc000222e94
> 
> 
> 
> Printout after fix:
> 
> #16 [ffffffc0be96f8d0] dhd_bus_rx_frame at ffffffbffc15a2f8 [wlan]
> #17 [ffffffc0be96f9b0] dhd_update_flow_prio_map at ffffffbffc161b18 [wlan]
> #18 [ffffffc0be96f9c0] dhd_update_flow_prio_map at ffffffbffc16033c [wlan]
> #19 [ffffffc0be96fa10] dhd_prot_process_ctrlbuf at ffffffbffc1630f8 [wlan]
> #20 [ffffffc0be96fab0] dhd_bus_ringbell at ffffffbffc156ff8 [wlan]
> #21 [ffffffc0be96faf0] dhd_bus_console_in at ffffffbffc15aa58 [wlan]
> #22 [ffffffc0be96fb20] dhd_bus_dpc at ffffffbffc15bfc8 [wlan]
> #23 [ffffffc0be96fb60] dhd_sched_dpc at ffffffbffc115fac [wlan]
> #24 [ffffffc0be96fb90] tasklet_action at ffffffc000223738
> #25 [ffffffc0be96fbb0] __do_softirq at ffffffc000222e94
> 
> 
> 
> From arm64.c:
> 
> 
> 
> static int
> 
> arm64_print_stackframe_entry(struct bt_info *bt, int level, struct
> arm64_stackframe *frame)
> 
> {
> 
> char *name, *name_plus_offset;
> ulong symbol_offset;
> struct syment *sp;
> struct load_module *lm;
> char buf[BUFSIZE];
> 
> name = closest_symbol(frame->pc);
> name_plus_offset = NULL;
> 
> if (bt->flags & BT_SYMBOL_OFFSET) {
> /*ADDED*/
> if (module_symbol(frame->pc, NULL, &lm, NULL, 0))
> sp = value_search_module(frame->pc, &symbol_offset);
> else
> /*END ADDED*/
> sp = value_search(frame->pc, &symbol_offset);
> 

Hi Jan,

I don't dispute that this is something to be fixed, but at the same
time I don't quite understand (1) why it's happening, and (2) how your
fix addresses it?  

The value_search() function does this if it's a module address:

struct syment *
value_search(ulong value, ulong *offset)
{
...
        if (IS_VMALLOC_ADDR(value))
                goto check_modules;

...
check_modules:
        sp = value_search_module(value, offset);

        return sp;
}

And even if IS_VMALLOC_ADDR() above fails, it should just fail to find it in
the base kernel symbols, and fall through to the value_search_module() call.

Does something different happen in your case?

I also note that in all cases "__this_module" is in the "(d)" section of each
module, and typically is the last/highest symbol value of the module.  So I'm 
confused as to how it's getting picked up as the closest value to all of
the different text addresses in the wlan module?

What does "sym -m wlan" look like?

Thanks,
  Dave



> 
> You probably also want to prevent calling module_symbol a second time later
> in the function.
> 
> 
> 
> Jan
> 
> 
> 
> Jan Karlsson
> 
> Senior Software Engineer
> 
> System Assurance
> 
> 
> 
> Sony Mobile Communications
> 
> Tel: +46 703 062 174
> 
> jan.karlsson at sonymobile.com
> 
> 
> 
> sonymobile.com
> 
> 
> 
> 
> 
> 
> 
> --
> Crash-utility mailing list
> Crash-utility at redhat.com
> https://www.redhat.com/mailman/listinfo/crash-utility