On Thu, Jun 29, 2023 at 9:46 PM Quentin Monnet <quentin@xxxxxxxxxxxxx> wrote: > > 2023-06-28 11:53 UTC+0000 ~ Yafang Shao <laoar.shao@xxxxxxxxx> > > If the kernel symbol is in a module, we will dump the module name as > > well. The square brackets around the module name are trimmed. > > > > Signed-off-by: Yafang Shao <laoar.shao@xxxxxxxxx> > > Reviewed-by: Quentin Monnet <quentin@xxxxxxxxxxxxx> > > --- > > tools/bpf/bpftool/xlated_dumper.c | 6 +++++- > > tools/bpf/bpftool/xlated_dumper.h | 2 ++ > > 2 files changed, 7 insertions(+), 1 deletion(-) > > > > diff --git a/tools/bpf/bpftool/xlated_dumper.c b/tools/bpf/bpftool/xlated_dumper.c > > index da608e10c843..567f56dfd9f1 100644 > > --- a/tools/bpf/bpftool/xlated_dumper.c > > +++ b/tools/bpf/bpftool/xlated_dumper.c > > @@ -46,7 +46,11 @@ void kernel_syms_load(struct dump_data *dd) > > } > > dd->sym_mapping = tmp; > > sym = &dd->sym_mapping[dd->sym_count]; > > - if (sscanf(buff, "%p %*c %s", &address, sym->name) != 2) > > + > > + /* module is optional */ > > + sym->module[0] = '\0'; > > + /* trim the square brackets around the module name */ > > + if (sscanf(buff, "%p %*c %s [%[^]]s", &address, sym->name, sym->module) < 2) > > Looking again at this patch, we should be good for parsing the module > name with the sscanf() because I don't expect a module name longer than > MODULE_MAX_NAME to show up, but I wonder what guarantee we have about > symbols names staying under SYM_MAX_NAME? Maybe we should specify the > max length to read, to remain on the safe side (or in case these limits > change in the future). But it doesn't have to be part of your set, I can > send a follow-up after that. Great, thanks for your work! -- Regards Yafang
