Re: [RFC] kallsyms: embed source file:line info in kernel stack traces

On Tue, 2026-03-03 at 07:47 -0500, Sasha Levin wrote:
> On Tue, Mar 03, 2026 at 10:31:46AM +0100, Jiri Slaby wrote:
> > On 03. 03. 26, 9:11, Geert Uytterhoeven wrote:
> > > On Tue, 3 Mar 2026 at 07:26, Richard Weinberger <[email protected]>
> > > wrote:
> > > > > Von: "Sasha Levin" <[email protected]>
> > > > > Add CONFIG_KALLSYMS_LINEINFO, which embeds a compact address-
> > > > > to-line
> > > > > lookup table in the kernel image so stack traces directly
> > > > > print source
> > > > > file and line number information:
> > > 
> > > > > Memory footprint measured with a simple KVM guest x86_64
> > > > > config:
> > > > > 
> > > > >  Table: 4,597,583 entries from 4,841 source files
> > > > >    lineinfo_addrs[]     4,597,583 x u32  = 17.5 MiB
> > > > >    lineinfo_file_ids[]  4,597,583 x u16  =  8.8 MiB
> > > > >    lineinfo_lines[]     4,597,583 x u32  = 17.5 MiB
> > > > >    file_offsets + filenames              ~  0.1 MiB
> > > > >    Total .rodata increase:              ~ 44.0 MiB
> > > > > 
> > > > >  vmlinux (stripped):  529 MiB -> 573 MiB  (+44 MiB / +8.3%)
> > > > 
> > > > Hm, that's a significant increase.
> > > 
> > > Other random idea: this data is only needed in case of a crash.
> > > Perhaps it can be stored compressed, and only be decompressed
> > > when needed, or even during look-up?
> > 
> > But obviously not when dumping OOM stack traces :P.
> 
> Right - I really wanted to avoid memory allocations or disk I/O here.
> 
> I'm sure we can come up with more efficient ways to store this
> information - I wanted to keep the initial version simple and easy
> for review.

When the system is crashing, efficiency (at least as long as the user
doesn't notice) isn't typically required, so if you did a linear search
instead of a binary one you could use compressed data that's amenable
to decompression using a stream algorithm (i.e. only requires a fixed
length buffer, not decompression of the entire thing), then you stream
through the compressed data a chunk at a time looking for the match.

Regards,

James