Re: [PATCH 2/3] slub: Print raw pointer addresses when debugging

[Stephen Boyd]

Quoting Petr Mladek (2021-05-24 04:32:13)
> On Wed 2021-05-19 18:35:38, Stephen Boyd wrote:
> > Obscuring the pointers that slub shows when debugging makes for some
> > confusing slub debug messages:
> >
> >  Padding overwritten. 0x0000000079f0674a-0x000000000d4dce17
> >
> > Those addresses are hashed for kernel security reasons. If we're trying
> > to be secure with slub_debug on the commandline we have some big
> > problems given that we dump whole chunks of kernel memory to the kernel
> > logs. Let's use %px here and dump buffers with the actual address for
> > the buffer instead of the hashed version so that the logs are
> > meaningful. This also helps if a kernel address is in some slub debug
> > report so we can figure out that the object is referencing itself.
>
> Please, do not do this!
>
> Use "no_hash_pointers" commandling option when you want to see
> raw pointers. It will make it clear when the kernel logs are save
> and when not.
>
> If "slub_debug" is useless with hashed pointers then it might enable
> "no_hash_pointers". But make sure that it prints the fat warning.

Ok I'll try to make slub_debug force on no_hash_pointers.

>
> This patch is the worst approach. We have to keep the number of "%px"
> callers at minimum to keep it maintainable. The only safe use-case is
> when the system is in panic() [*]. If the pointers might be printed
> at any time then users should be warned by the fat message printed
> by "no_hash_pointers".
>
>
> [*] Raw pointers are currently printed also by Oops/WARN messages.
>     It is from historic reasons. Anyway, they are fat warnings
>     on its own. The system often need to get reported anyway.
>

Got it. The slub debug messages are usually followed by stuff blowing up
and the system crashing but it's possible that the automatic fixup code
will save us. When you have things scribbling all over the place it
doesn't end well.