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

Jürgen Groß <[email protected]> Tue, 3 Mar 2026 14:08:43 +0100

Newsgroups	dev.linux.lists.ksummit
Message-ID	<[email protected]>

On 03.03.26 13:58, James Bottomley wrote:
> 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.

And for this data the compression algorithm could be quite simple:

Build chunks of e.g. 1000 entries, allowing to do a quick search for
finding the correct chunk, then scan through the chunk to find the
entry.

Put the start address at the beginning of each chunk, then use a lsb128
coded offset for each entry (offset always relative to last entry, so
most entries would need only 1 byte additional address information).

I guess file ids are fine as u16.

Line numbers could be lsb128 encoded, too, limiting most entries to
2 bytes of additional information.

This simple scheme would already save roughly 50% of the needed space.


Juergen

OpenPGP_0xB0DE9DD628BF132F.asc (application/pgp-keys, 3.6 KB)

OpenPGP_signature.asc (application/pgp-signature, 495 B)