(2014/06/19 15:40), Suzuki K. Poulose wrote:

On 06/19/2014 10:22 AM, Masami Hiramatsu wrote:

quoted

(2014/06/19 10:30), Michael Ellerman wrote:

quoted

On Wed, 2014-06-18 at 17:46 +0900, Masami Hiramatsu wrote:

quoted

(2014/06/18 16:56), Michael Ellerman wrote:

quoted

On Fri, 2014-06-06 at 15:38 +0900, Masami Hiramatsu wrote:

quoted

Ping?

I guess this should go to 3.16 branch, shouldn't it?

quoted

quoted

diff --git a/arch/powerpc/include/asm/types.h b/arch/powerpc/include/asm/types.h
index bfb6ded..8b89d65 100644
--- a/arch/powerpc/include/asm/types.h
+++ b/arch/powerpc/include/asm/types.h

@@ -25,6 +25,17 @@ typedef struct {
 	unsigned long env;
 } func_descr_t;
 
+#if defined(CONFIG_PPC64) && (!defined(_CALL_ELF) || _CALL_ELF == 1)
+/*
+ * On PPC64 ABIv1 the function pointer actually points to the
+ * function's descriptor. The first entry in the descriptor is the
+ * address of the function text.
+ */
+#define function_entry(fn)	(((func_descr_t *)(fn))->entry)
+#else
+#define function_entry(fn)	((unsigned long)(fn))
+#endif

We already have ppc_function_entry(), can't you use that?

I'd like to ask you whether the address which ppc_function_entry() returns on
PPC ABIv2 is really same address in kallsyms or not.
As you can see, kprobes uses function_entry() to get the actual entry address
where kallsyms knows. I have not much information about that, but it seems that
the "global entry point" is the address which kallsyms knows, isn't it?

OK. I'm not sure off the top of my head which address kallsyms knows about, but
yes it's likely that it is the global entry point.

I recently sent a patch to add ppc_global_function_entry(), because we need it
in the ftrace code. Once that is merged you could use that.

Yeah, I could use that. But since this is used in arch-independent code (e.g. IA64
needs similar macro), I think we'd better define function_entry() in asm/types.h for
general use (for kallsyms), and rename ppc_function_entry to local_function_entry()
in asm/code-patching.h.

quoted

How do you hit the original problem, you don't actually specify in your commit
message? Something with kprobes obviously, but what exactly? I'll try and
reproduce it here.

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? And if so, how I can verify when initializing blacklist?
(should I better use kallsyms_lookup() and kallsyms_lookup_name() for
verification?)

Thank you,

1) Dump the black_list via xmon ( see :
https://lkml.org/lkml/2014/5/29/893 ) and verify the entries.

or

2) Issue a kprobe on a black listed entry and hit a success,(which we
will, since we don't check the actual function address).

Thanks
Suzuki

quoted

Thank you,

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