Re: [PATCH v6 1/4] kallsyms: embed source file:line info in kernel stack traces

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