Re: [PATCH v6 1/4] kallsyms: embed source file:line info in kernel stack traces
From: sashiko-bot@kernel.org
Date: 2026-07-06 14:44:09
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 [off-list ref] 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.
quoted hunk ↗ jump to hunk
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; }
quoted hunk ↗ jump to hunk
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/20260706142914.2398993-1-sashal@kernel.org?part=1