Re: [PATCH v2 2/2] kallsyms: Document why unresolved symbols are revealed

[Petr Mladek]

On Mon 2026-08-31 12:49:28, Steven Rostedt wrote:
> On Mon, 31 Aug 2026 15:37:29 +0200
> Sebastian Andrzej Siewior <bigeasy@xxxxxxxxxxxxx> wrote:
> 
> > Could someone yell here, please? I convinced myself that hiding
> > unresolved pointers is the good thing to do here since a "wrong" pointer
> > would be seen in backtrace anyway.
> > 
> > Thread starts at
> > 	https://lore.kernel.org/all/20260821152614.2202196-1-bigeasy@xxxxxxxxxxxxx/
> 
> I wonder if we should just tagged hash values as such:
> 
> | [    1.498171]  <TASK>
> | [    1.498172]  00000000cb9bc262 [hash]
> | [    1.498174]  ? 00000000eb5021dd [hash]
> | [    1.498176]  00000000ed1a9938 [hash]
> | [    1.498178]  </TASK>
> 
> So that people will know that the value is just some random hash value and
> not a real address.
> 
> Although rather useless in call stacks, I like hash values because the same
> address will show up the same.
> 
> Having '[unknown]' may also be confusing because it doesn't really say
> "why" it was unknown. But having a number goes back to what it always did.
> Hashing it with a "[hash]" marker will also let people know the value was
> hashed.

I like this idea. I just wonder whether it might confuse some parsers
who expect that symbol name is one string. %ps, %pS, %pB are used
in various context.

I think about adding the hint into the hashed value, e.g. by using
'h' instead of the highest number, something like:

 [    1.498171]  <TASK>
 [    1.498172]  h0000000cb9bc262
 [    1.498174]  ? h0000000eb5021dd
 [    1.498176]  h0000000ed1a9938
 [    1.498178]  </TASK>

But 'h' is not a valid number number so it might confuse parsers as
well. And it is not that user friedly either.

So, I still like more Steven's variant with [hash].

Best Regards,
Petr