Linux Modules
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Sasha Levin" <sashal@kernel.org>,
	"Andrew Morton" <akpm@linux-foundation.org>,
	"Masahiro Yamada" <masahiroy@kernel.org>,
	"Luis Chamberlain" <mcgrof@kernel.org>,
	"Linus Torvalds" <torvalds@linux-foundation.org>,
	"Richard Weinberger" <richard@nod.at>,
	"Juergen Gross" <jgross@suse.com>,
	"Geert Uytterhoeven" <geert@linux-m68k.org>,
	"James Bottomley" <James.Bottomley@HansenPartnership.com>
Cc: "Jonathan Corbet" <corbet@lwn.net>,
	"Nathan Chancellor" <nathan@kernel.org>,
	"Nicolas Schier" <nsc@kernel.org>,
	"Petr Pavlu" <petr.pavlu@suse.com>,
	"Daniel Gomez" <da.gomez@kernel.org>,
	"Aaron Tomlin" <atomlin@atomlin.com>,
	"Greg KH" <gregkh@linuxfoundation.org>,
	"Petr Mladek" <pmladek@suse.com>,
	"Steven Rostedt" <rostedt@goodmis.org>,
	"Kees Cook" <kees@kernel.org>,
	"Peter Zijlstra" <peterz@infradead.org>,
	"Thorsten Leemhuis" <linux@leemhuis.info>,
	"Vlastimil Babka" <vbabka@kernel.org>,
	"Helge Deller" <deller@gmx.de>,
	"Randy Dunlap" <rdunlap@infradead.org>,
	"Laurent Pinchart" <laurent.pinchart@ideasonboard.com>,
	"Vivian Wang" <wangruikang@iscas.ac.cn>,
	"Zhen Lei" <thunder.leizhen@huawei.com>,
	"Sami Tolvanen" <samitolvanen@google.com>,
	linux-kbuild@vger.kernel.org, linux-modules@vger.kernel.org
Subject: Re: [PATCH v11 1/4] kallsyms: embed source file:line info in kernel stack traces
Date: Sat, 07 Nov 2026 13:24:59 +0000	[thread overview]
Message-ID: <sashiko-outbox-202909@kernel.org> (raw)
In-Reply-To: <20261106132432.248387-2-sashal@kernel.org>

Thank you for your contribution! Sashiko AI review found 3 potential
issues to consider:
- [Medium] kallsyms: collect_symbol_starts() excludes STT_NOTYPE and
  unsized symbols
- [Medium] kallsyms: collect_symbol_starts() includes SHN_ABS and
  mapping symbols
- [Low] scripts: missing libelf in pkg-config query for gen_lineinfo in
  Makefile
--

commit 5d77a3194e4ba642dd6e711d224cf8351955c65e
Author: Sasha Levin <sashal@kernel.org>

kallsyms: embed source file:line info in kernel stack traces

This commit adds CONFIG_KALLSYMS_LINEINFO and the scripts/gen_lineinfo host
tool to extract DWARF .debug_line mappings from vmlinux and embed source
file:line annotations into kernel stack traces.

> diff --git a/scripts/Makefile b/scripts/Makefile
> index d7fbb7ca098b1..94b09cf7c1839 100644
> --- a/scripts/Makefile
> +++ b/scripts/Makefile
> @@ -4,6 +4,7 @@
>  # the kernel for the build process.
>  
>  hostprogs-always-y				+= kallsyms
> +hostprogs-always-$(CONFIG_KALLSYMS_LINEINFO)		+= gen_lineinfo
>  hostprogs-always-$(BUILD_C_RECORDMCOUNT)		+= recordmcount
>  hostprogs-always-$(CONFIG_BUILDTIME_TABLE_SORT)		+= sorttable
>  hostprogs-always-$(CONFIG_ASN1)				+= asn1_compiler
> @@ -40,6 +41,8 @@ HOSTCFLAGS_asn1_compiler.o = -I$(srctree)/include
>  HOSTCFLAGS_sign-file.o = $(shell $(HOSTPKG_CONFIG) --cflags libcrypto 2> /dev/null)
>  HOSTCFLAGS_sign-file.o += -I$(srctree)/tools/include/uapi/
>  HOSTLDLIBS_sign-file = $(shell $(HOSTPKG_CONFIG) --libs libcrypto 2> /dev/null || echo -lcrypto)
> +HOSTCFLAGS_gen_lineinfo.o = $(shell $(HOSTPKG_CONFIG) --cflags libdw 2> /dev/null)
> +HOSTLDLIBS_gen_lineinfo = $(shell $(HOSTPKG_CONFIG) --libs libdw 2> /dev/null || echo -ldw -lelf)
>  
>  ifdef CONFIG_UNWINDER_ORC
>  ifeq ($(ARCH),x86_64)

[Severity: Low]
Should HOSTCFLAGS_gen_lineinfo.o and HOSTLDLIBS_gen_lineinfo query
pkg-config for both libdw and libelf?

scripts/gen_lineinfo.c directly calls libelf and gelf functions such as
elf_begin() and gelf_getsym().  In elfutils, libdw.pc lists libelf under
Requires.private and outputs only -ldw for --libs, so when pkg-config
succeeds the fallback is skipped and linking gen_lineinfo fails with
undefined libelf references on linkers using --no-copy-dt-needed-entries.

> diff --git a/scripts/gen_lineinfo.c b/scripts/gen_lineinfo.c
> new file mode 100644
> index 0000000000000..1b347d07b7ad5
> --- /dev/null
> +++ b/scripts/gen_lineinfo.c

[ ... ]

> +static void collect_symbol_starts(Elf *elf, unsigned long long text_addr)
> +{
> +	Elf_Scn *scn = NULL;
> +	GElf_Shdr shdr;
> +
> +	while ((scn = elf_nextscn(elf, scn)) != NULL) {
> +		Elf_Data *data;
> +		size_t nsyms;
> +
> +		if (!gelf_getshdr(scn, &shdr))
> +			continue;
> +		if (shdr.sh_type != SHT_SYMTAB || !shdr.sh_entsize)
> +			continue;
> +
> +		data = elf_getdata(scn, NULL);
> +		if (!data)
> +			continue;
> +
> +		nsyms = shdr.sh_size / shdr.sh_entsize;
> +		for (size_t i = 0; i < nsyms; i++) {
> +			GElf_Sym sym;
> +			unsigned long long raw;
> +
> +			if (!gelf_getsym(data, i, &sym))
> +				continue;
> +			switch (GELF_ST_TYPE(sym.st_info)) {
> +			case STT_FUNC:
> +			case STT_NOTYPE:
> +				break;
> +			default:
> +				continue;
> +			}
> +			if (sym.st_value < text_addr)
> +				continue;
> +			if (text_end_addr && sym.st_value >= text_end_addr)
> +				continue;

[Severity: Medium]
Can unfiltered SHN_ABS, mapping ($x, $d, $a, $t) and local (.L*) symbols in
collect_symbol_starts() corrupt the symbol extents in text_starts[]?

Any STT_NOTYPE symbol whose value falls in [_text, _etext) is added to
text_starts[] without checking sym.st_shndx or symbol names.  When the loop
at the end of collect_symbol_starts() infers sizes for unsized symbols from
the distance to the next entry (while leaving the final entry at size 0 if
unsized), internal mapping or .L* labels truncate the inferred extent of the
enclosing routine, and mapping or SHN_ABS symbols receive non-zero sizes of
their own.  starts_new_sequence() -> symbol_extent_at() then misclassifies
DWARF sequence boundaries in resolve_cu_row_groups(), dropping valid opening
line rows or keeping bogus extents.

> +
> +			raw = sym.st_value - text_addr;
> +			if (raw > UINT_MAX)
> +				continue;
> +
> +			if (num_sym_starts >= sym_starts_capacity) {
> +				sym_starts_capacity = sym_starts_capacity ?
> +					sym_starts_capacity * 2 : 16384;
> +				sym_starts = xrealloc(sym_starts,
> +						      sym_starts_capacity *
> +						      sizeof(*sym_starts));
> +			}
> +			if (num_text_starts >= text_starts_capacity) {
> +				text_starts_capacity = text_starts_capacity ?
> +					text_starts_capacity * 2 : 16384;
> +				text_starts = xrealloc(text_starts,
> +						       text_starts_capacity *
> +						       sizeof(*text_starts));
> +			}
> +			text_starts[num_text_starts].offset = (unsigned int)raw;
> +			text_starts[num_text_starts].size =
> +				sym.st_size > UINT_MAX ? UINT_MAX :
> +				(unsigned int)sym.st_size;
> +			num_text_starts++;
> +
> +			if (GELF_ST_TYPE(sym.st_info) != STT_FUNC)
> +				continue;
> +
> +			sym_starts[num_sym_starts].offset = (unsigned int)raw;
> +			sym_starts[num_sym_starts].size =
> +				sym.st_size > UINT_MAX ? UINT_MAX :
> +				(unsigned int)sym.st_size;
> +			num_sym_starts++;
> +		}
> +	}
> +
> +	sort_starts(sym_starts, &num_sym_starts);
> +	sort_starts(text_starts, &num_text_starts);
> +
> +	/*
> +	 * An unsized label reaches the next symbol, and a sequence beginning
> +	 * there cannot run past it.
> +	 */
> +	for (unsigned int i = 1; i < num_text_starts; i++) {
> +		if (!text_starts[i - 1].size)
> +			text_starts[i - 1].size = text_starts[i].offset -
> +						  text_starts[i - 1].offset;
> +	}
> +}

[Severity: Medium]
Does excluding STT_NOTYPE and unsized symbols from sym_starts[] leave stack
frames in those symbols without lineinfo annotations?

At runtime, __sprint_symbol() resolves kallsyms symbols regardless of whether
they are STT_FUNC or STT_NOTYPE, and kallsyms_lookup_lineinfo() rejects any
entry below sym_start - _text.  However, sym_starts[] excludes STT_NOTYPE
symbols (such as Clang .cold split subfunctions, SYM_CODE_START assembly
routines, SYM_INNER_LABEL entry points like entry_SYSCALL_64_after_hwframe,
and CONFIG_PROPELLER_CLANG basic-block symbols) and never backfills zero
st_size values.  As a result, synthesize_symbol_starts() does not copy
covering rows to their start addresses and deduplicate() can drop entries
at their start when the file and line match the previous entry, causing
kallsyms_lookup_lineinfo() to fail the min_offset boundary check.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261106132432.248387-1-sashal@kernel.org?part=1

  parent reply	other threads:[~2026-11-07 13:25 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-06 13:24 [PATCH v11 0/4] kallsyms: embed source file:line info in kernel stack traces Sasha Levin
2026-11-06 13:24 ` [PATCH v11 1/4] " Sasha Levin
2026-11-06 14:52   ` Helge Deller
2026-11-07 13:24   ` sashiko-bot [this message]
2026-11-06 13:24 ` [PATCH v11 2/4] kallsyms: extend lineinfo to loadable modules Sasha Levin
2026-11-06 13:24 ` [PATCH v11 3/4] kallsyms: delta-compress lineinfo tables for ~2.7x size reduction Sasha Levin
2026-11-06 13:24 ` [PATCH v11 4/4] kallsyms: add KUnit tests for lineinfo feature Sasha Levin
2026-11-07 13:25   ` sashiko-bot

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=sashiko-outbox-202909@kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=James.Bottomley@HansenPartnership.com \
    --cc=akpm@linux-foundation.org \
    --cc=atomlin@atomlin.com \
    --cc=corbet@lwn.net \
    --cc=da.gomez@kernel.org \
    --cc=deller@gmx.de \
    --cc=geert@linux-m68k.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=jgross@suse.com \
    --cc=kees@kernel.org \
    --cc=laurent.pinchart@ideasonboard.com \
    --cc=linux-kbuild@vger.kernel.org \
    --cc=linux-modules@vger.kernel.org \
    --cc=linux@leemhuis.info \
    --cc=masahiroy@kernel.org \
    --cc=mcgrof@kernel.org \
    --cc=nathan@kernel.org \
    --cc=nsc@kernel.org \
    --cc=peterz@infradead.org \
    --cc=petr.pavlu@suse.com \
    --cc=pmladek@suse.com \
    --cc=rdunlap@infradead.org \
    --cc=richard@nod.at \
    --cc=rostedt@goodmis.org \
    --cc=samitolvanen@google.com \
    --cc=sashal@kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    --cc=thunder.leizhen@huawei.com \
    --cc=torvalds@linux-foundation.org \
    --cc=vbabka@kernel.org \
    --cc=wangruikang@iscas.ac.cn \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox