On Sat, 1 Feb 2025 16:23:00 +0900 "Masami Hiramatsu (Google)" <mhiramat@xxxxxxxxxx> wrote: > Hi, > > Here is the 2nd version of adding relative stacktrace for tracing. > The previous version is here; > > https://lore.kernel.org/all/173807861687.1525539.15082309716909038251.stgit@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx/ > > In this version, I changed the idea to only use the first 32bit of > the build_id of the modules instead of using live hash/id to identify > the module. Also, save the offset from the .text section for each > module instead of using the offset from the _stext for the module > address. (For the core kernel text address, keep using the offset > from _stext.) > > This brings the following benefits: > - Do not need to save the live module allocation information on > somewhere in the reserved memory. > - Easy to find the module offline. > - We can ensure there are only offsets from the base, no KASLR info. > > Moreover, encode/decode module build_id, we can show the module name > with the symbols on stacktrace. > > Thus, this relative stacktrace is a better option for the persistent > ring buffer with security restricted environment (e.g. no kallsyms > access from user.) > > # echo 1 > options/relative-stacktrace > # modprobe trace_events_sample > # echo stacktrace > events/sample-trace/foo_bar/trigger > # cat trace > event-sample-1622 [004] ...1. 397.542659: <stack trace> > => event_triggers_post_call > => trace_event_raw_event_foo_bar [trace_events_sample] > => do_simple_thread_func [trace_events_sample] > => simple_thread [trace_events_sample] > => kthread > => ret_from_fork > => ret_from_fork_asm > I thought we decided that we didn't need the relative stack trace? That all we need to do is to expose the offset from the last boot, and a list of modules that were loaded and their addresses, and then we can easily decipher the stack traces into human readable format? -- Steve
