From: Petr Mladek <pmladek@suse.com>
To: Stephen Boyd <swboyd@chromium.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
linux-kernel@vger.kernel.org, Christoph Lameter <cl@linux.com>,
Pekka Enberg <penberg@kernel.org>,
David Rientjes <rientjes@google.com>,
Joonsoo Kim <iamjoonsoo.kim@lge.com>,
Vlastimil Babka <vbabka@suse.cz>,
linux-mm@kvack.org
Subject: Re: [PATCH 2/3] slub: Print raw pointer addresses when debugging
Date: Mon, 24 May 2021 13:32:13 +0200 [thread overview]
Message-ID: <20210524113213.h33k3t2exr5rlwin@pathway.suse.cz> (raw)
In-Reply-To: <20210520013539.3733631-3-swboyd@chromium.org>
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.
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.
Best Regards,
Petr
next prev parent reply other threads:[~2021-05-24 11:32 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-05-20 1:35 [PATCH 0/3] slub: Print non-hashed pointers in slub debugging Stephen Boyd
2021-05-20 1:35 ` [PATCH 1/3] lib/hexdump: Add a raw pointer printing format for " Stephen Boyd
2021-05-24 5:11 ` David Rientjes
2021-05-24 11:36 ` Petr Mladek
2021-05-20 1:35 ` [PATCH 2/3] slub: Print raw pointer addresses when debugging Stephen Boyd
2021-05-24 11:32 ` Petr Mladek [this message]
2021-05-25 6:21 ` Stephen Boyd
2021-05-20 1:35 ` [PATCH 3/3] slub: Actually use 'message' in restore_bytes() Stephen Boyd
2021-05-20 10:02 ` Vlastimil Babka
2021-05-24 5:12 ` David Rientjes
2021-05-25 7:37 ` Joe Perches
2021-05-26 2:32 ` Stephen Boyd
2021-05-26 2:38 ` Joe Perches
2021-05-20 10:01 ` [PATCH 0/3] slub: Print non-hashed pointers in slub debugging Vlastimil Babka
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20210524113213.h33k3t2exr5rlwin@pathway.suse.cz \
--to=pmladek@suse.com \
--cc=akpm@linux-foundation.org \
--cc=cl@linux.com \
--cc=iamjoonsoo.kim@lge.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=penberg@kernel.org \
--cc=rientjes@google.com \
--cc=swboyd@chromium.org \
--cc=vbabka@suse.cz \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).