[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CA+55aFyaLgbocKa4Ec1J4Z12p4-N66MQGOj-HLaxP8RSW8NOrw@mail.gmail.com>
Date: Wed, 24 Aug 2016 14:03:58 -0400
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Josh Poimboeuf <jpoimboe@...hat.com>
Cc: Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...nel.org>,
"H . Peter Anvin" <hpa@...or.com>,
"the arch/x86 maintainers" <x86@...nel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Andy Lutomirski <luto@...capital.net>,
Steven Rostedt <rostedt@...dmis.org>,
Brian Gerst <brgerst@...il.com>,
Kees Cook <keescook@...omium.org>,
Peter Zijlstra <peterz@...radead.org>,
Frederic Weisbecker <fweisbec@...il.com>,
Byungchul Park <byungchul.park@....com>,
Nilay Vaish <nilayvaish@...il.com>
Subject: Re: [PATCH 3/6] x86/dumpstack: make printk_stack_address() more
generally useful
On Wed, Aug 24, 2016 at 12:50 PM, Josh Poimboeuf <jpoimboe@...hat.com> wrote:
> Change printk_stack_address() to be useful when called by an unwinder
> outside the context of dump_trace().
...
> printk("%s [<%p>] %s%pB\n",
> - (char *)data, (void *)address, reliable ? "" : "? ",
> + log_lvl, (void *)address, reliable ? "" : "? ",
> (void *)address);
Side note: we should just remove the "[<hex>]" thing entirely, I
think. It's not just redundant, but when people care about kernel
address randomization it ends up spilling the beans on the offset in
warnings (in oopses you can generally find the data in the stack
backtraces, which we probably should remove too as useless).
So it would be just
printk("%s %s%pB\n", log_lvl, reliable ? "" : "? ", (void *)address);
instead.
For the non-kallsyms case we _could_ also just make the '%pB' format
add the [<>] markers back in case somebody still uses the user-space
kallsyms script that looks up hex numbers.
Right now the hex numbers are not only useless in stack dumps (since
you can't look up symbols using them anyway thanks to randomization),
they are noise that makes the stack traces harder to read. So let's
just remove them?
I realize that is entirely orthogonal to this particular patch, but it
happened to touch this file.
No objections to this series other than that comment.
Linus
Powered by blists - more mailing lists