[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <67a0aad8-5412-60f8-6481-562d37995eb2@gmx.de>
Date: Fri, 8 Sep 2017 20:28:13 +0200
From: Helge Deller <deller@....de>
To: "Luck, Tony" <tony.luck@...el.com>,
Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>
Cc: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Sergey Senozhatsky <sergey.senozhatsky@...il.com>,
Petr Mladek <pmladek@...e.com>,
Andrew Morton <akpm@...ux-foundation.org>,
"Yu, Fenghua" <fenghua.yu@...el.com>,
Benjamin Herrenschmidt <benh@...nel.crashing.org>,
Paul Mackerras <paulus@...ba.org>,
Michael Ellerman <mpe@...erman.id.au>
Subject: Re: [PATCH 00/14] Fix wrong %pF and %pS printk format specifier
usages
On 08.09.2017 19:25, Luck, Tony wrote:
> On Fri, Sep 08, 2017 at 03:18:30PM +0900, Sergey Senozhatsky wrote:
>> if the addr is not in kernel .text, then try dereferencing it and check
>> if the dereferenced addr is in kernel .text.
>
> If it really is a function pointer, then we know that it is safe
> to dereference. But if it isn't, then maybe not?
>
> If it is a function pointer then dereferening will indeed give
> us a .text address. But if it isn't, it might still give us a
> .text address (we could reduce the probability of a false hit
> by checking that the .text address was exactly on a symbol with
> no offset ... but data values that happen to be the addresses of
> function entry points are possible).
I don't like this kind of trying to figure out at runtime at all.
It's too much guessing in here IMHO.
What about this idea:
For %pF we always have pointers to functions, e.g.:
printk("Going to call: %pF\n", gettimeofday);
printk("Going to call: %pF\n", p->func);
and for %pS most (if not all) usages use some kind of casting
from "unsigned long" to "void *", e.g.:
printk("%s: called from %pS\n", __func__, (void *)_RET_IP_);
printk("%s: called from %pS\n", __func__, (void *)__builtin_return_address(0));
printk("Faulted at %pS\n", (void *)regs->ip);
So, what if we for the %pS case simply take the type as it is
(unsigned long) and introduce a new printk-format, e.g. "%luS" ?
The %pS examples above then become:
printk("%s: called from %luS\n", __func__, _RET_IP_);
printk("%s: called from %luS\n", __func__, __builtin_return_address(0));
printk("Faulted at %luS\n", regs->ip);
That way we don't need type-casting, gain compile-time type
checks from the compiler, and we could add a checkpatch (or occinelle)
check which checks for the combination of %pF/%pS and "void*" keyword
and suggest to use %luS.
Opinions?
Helge
Powered by blists - more mailing lists