[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <bfb425fb-0254-c1e3-62b3-d55a7cbb46ae@kernel.org>
Date: Wed, 10 Feb 2021 11:21:52 -0600
From: Timur Tabi <timur@...nel.org>
To: Steven Rostedt <rostedt@...dmis.org>,
Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>
Cc: Petr Mladek <pmladek@...e.com>,
Sergey Senozhatsky <sergey.senozhatsky@...il.com>,
Vlastimil Babka <vbabka@...e.cz>,
Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
Matthew Wilcox <willy@...radead.org>,
akpm@...ux-foundation.org,
Linus Torvalds <torvalds@...ux-foundation.org>,
roman.fietze@...na.com, Kees Cook <keescook@...omium.org>,
John Ogness <john.ogness@...utronix.de>,
akinobu.mita@...il.com, glider@...gle.com,
Andrey Konovalov <andreyknvl@...gle.com>,
Marco Elver <elver@...gle.com>,
Rasmus Villemoes <linux@...musvillemoes.dk>,
Pavel Machek <pavel@....cz>, linux-kernel@...r.kernel.org,
linux-mm@...ck.org
Subject: Re: [PATCH 0/3][RESEND] add support for never printing hashed
addresses
On 2/10/21 10:46 AM, Steven Rostedt wrote:
> Now the question is, why do you need the unhashed pointer?
>
> Currently, the instruction pointer is what is fine right? You get the
> a function and its offset. If there's something that is needed, perhaps we
> should look at how to fix that, instead of just unhashing all pointers by
> default.
The original version of this patch only fixed print_hex_dump(), because
hashed addresses didn't make any sense for that. Each address is
incremented by 16 or 32, but since they were all hashed, they may as
well have been random numbers.
Powered by blists - more mailing lists