Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider: - [Medium] Assembly routines and other un-annotated symbols will be falsely annotated with the file and line number of the preceding C function because the binary search does not restrict lookups to the boundaries of the resolved symbol. - [Low] Unchecked `strdup` return value causes a segmentation fault on memory allocation failure in the `gen_lineinfo` host tool. --
commit 8ad0e66e84394fea4bf24efbedda7eb50bbe8269 Author: Sasha Levin <[email protected]> kallsyms: embed source file:line info in kernel stack traces This commit adds CONFIG_KALLSYMS_LINEINFO to embed an address-to-line lookup table in the kernel image. A new host tool extracts DWARF data at build time, allowing stack traces to directly include source file and line number information. > diff --git a/kernel/kallsyms.c b/kernel/kallsyms.c > index aec2f06858afd..1e3f527b13988 100644 > --- a/kernel/kallsyms.c > +++ b/kernel/kallsyms.c > @@ -497,6 +544,23 @@ static int __sprint_symbol(char *buffer, unsigned long > address, > len += sprintf(buffer + len, "]"); > } > > + /* > + * Append "(file:line)" only for stack-backtrace consumers. Plain > + * sprint_symbol() backs %ps, and many existing format strings tack > + * literal "()" after %ps to indicate a function call ("foo() > + * replaced with bar()"); appending lineinfo there would produce a > + * confusing "foo (file:line)()". > + */ > + if (add_lineinfo && IS_ENABLED(CONFIG_KALLSYMS_LINEINFO) && !modname) { > + const char *li_file; > + unsigned int li_line; > + > + if (kallsyms_lookup_lineinfo(address, > + &li_file, &li_line)) [Severity: Medium] Will this falsely annotate assembly routines or un-annotated symbols with the file and line number of the preceding C function? The caller has access to the resolved symbol's size and offset but fails to pass this bounding information to kallsyms_lookup_lineinfo(). The binary search in kallsyms_lookup_lineinfo() does not restrict lookups to the boundaries of the resolved symbol, finding the closest preceding entry. Since gen_lineinfo explicitly ignores DW_LNE_end_sequence markers, could this regression cause the search to bleed across symbol boundaries? > + len += snprintf(buffer + len, KSYM_SYMBOL_LEN - len, > + " (%s:%u)", li_file, li_line); > + } > + > return len; > } > diff --git a/scripts/gen_lineinfo.c b/scripts/gen_lineinfo.c > new file mode 100644 > index 0000000000000..699e760178f09 > --- /dev/null > +++ b/scripts/gen_lineinfo.c > @@ -0,0 +1,557 @@ [ ... ] > + if (num_files >= files_capacity) { > + files_capacity = files_capacity ? files_capacity * 2 : 4096; > + files = realloc(files, files_capacity * sizeof(*files)); > + if (!files) { > + fprintf(stderr, "out of memory\n"); > + exit(1); > + } > + } > + files[num_files].name = strdup(name); [Severity: Low] Does this code handle memory allocation failures? strdup() can return NULL on failure, which would be assigned directly to the files array here and could cause a segmentation fault when later dereferenced via strlen(). > + files[num_files].id = num_files; > + > + /* Insert into hash table (points to files[] entry) */ > + file_hash[h].name = files[num_files].name; > + file_hash[h].id = num_files; > + > + num_files++; > + return num_files - 1; > +} -- Sashiko AI review ยท https://sashiko.dev/#/patchset/[email protected]?part=1
