[lkml]   [2017]   [Sep]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [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.



 \ /
  Last update: 2017-09-08 20:29    [W:0.140 / U:0.044 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site