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

[Sebastian Andrzej Siewior]

On 2026-09-01 09:23:37 [+0200], Petr Mladek wrote:
> 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].

While it does make sense to add [hash] to make it obvious it breaks
formatting for some of the %p users where %p is expected to have a fixed
length depending on 32/64 bit. Here, it is a %pS so adding extra it
wouldn't break anything but I don't think it should be different between
%p and %pS assuming we do print the hash instead 'unknown'.

> Best Regards,
> Petr

Sebastian