(2014/06/20 9:37), Michael Ellerman wrote:

On Thu, 2014-06-19 at 20:20 +0900, Masami Hiramatsu wrote:

quoted

(2014/06/19 20:01), Masami Hiramatsu wrote:

quoted

quoted

quoted

quoted

quoted

Ah, those messages should be shown in dmesg when booting if it doesn't work,
because the messages are printed by initialization process of kprobe blacklist.
So, reproducing it is just enabling CONFIG_KPROBES and boot it.

Well,  we don't get those messages on Power, since the kallsyms has the
entries for ".function_name". The correct way to verify is, either  :

Hmm, that seems another issue on powerpc. Is that expected(and designed)
behavior?

AFAIK, yes, it is.
To be more precise :

we have 'foo' and '.foo' for a function foo(), where 'foo' points to the
function_entry and '.foo' points to the actual function.

Ah, I see. So if we run

  func_ptr p = foo;
  return p == kallsyms_lookup_name(".foo");

it returns true.

One more thing I should know, is the address of ".function_name" within the
kernel text? In other words, does kernel_text_address() return true for that
address? If not, it's easy to verify the address.

Yes. That is the text address, kernel_text_address() should definitely return
true.

On 64-bit, ABIv1, "foo" points to the function descriptor, in the ".opd"
section.

".foo" points to the actual text of the function, in ".text".

Hmm, I misunderstood that. Anyway, we can verify it by kernel_text_address().

On 64-bit, ABIv2, "foo" points to the text in ".text". There are no dot
symbols.

OK, in that case, kernel_text_address() check is still available. :)

Thank you,


-- 
Masami HIRAMATSU
Software Platform Research Dept. Linux Technology Research Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu.pt@hitachi.com