Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757777AbaFSLBx (ORCPT ); Thu, 19 Jun 2014 07:01:53 -0400 Received: from mail4.hitachi.co.jp ([133.145.228.5]:39149 "EHLO mail4.hitachi.co.jp" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752358AbaFSLBv (ORCPT ); Thu, 19 Jun 2014 07:01:51 -0400 Message-ID: <53A2C315.9030006@hitachi.com> Date: Thu, 19 Jun 2014 20:01:41 +0900 From: Masami Hiramatsu Organization: Hitachi, Ltd., Japan User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: "Suzuki K. Poulose" Cc: Michael Ellerman , Benjamin Herrenschmidt , Tony Luck , Paul Mackerras , Jeremy Fitzhardinge , linux-ia64@vger.kernel.org, sparse@chrisli.org, "H. Peter Anvin" , Thomas Gleixner , linux-tip-commits@vger.kernel.org, anil.s.keshavamurthy@intel.com, Ingo Molnar , Fenghua Yu , Arnd Bergmann , Rusty Russell , Chris Wright , yrl.pp-manager.tt@hitachi.com, akataria@vmware.com, Tony Luck , Kevin Hao , Linus Torvalds , rdunlap@infradead.org, Linux Kernel Mailing List , dl9pf@gmx.de, Andrew Morton , linuxppc-dev@lists.ozlabs.org, "David S. Miller" Subject: Re: Re: [RFT PATCH -next v3] [BUGFIX] kprobes: Fix "Failed to find blacklist" error on ia64 and ppc64 References: <5387F150.5000307@hitachi.com> <20140530031838.17427.75896.stgit@ltc230.yrl.intra.hitachi.co.jp> <539161D6.7020508@hitachi.com> <1403078179.32307.7.camel@concordia> <53A15201.7060404@hitachi.com> <1403141433.4768.1.camel@concordia> <53A26C99.6060000@hitachi.com> <53A285D0.1030106@in.ibm.com> <53A2908E.2000806@hitachi.com> <53A2B136.108@in.ibm.com> In-Reply-To: <53A2B136.108@in.ibm.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org (2014/06/19 18:45), Suzuki K. Poulose wrote: > On 06/19/2014 12:56 PM, Masami Hiramatsu wrote: >> (2014/06/19 15:40), Suzuki K. Poulose wrote: >>> On 06/19/2014 10:22 AM, Masami Hiramatsu wrote: >>>> (2014/06/19 10:30), Michael Ellerman wrote: >>>>> On Wed, 2014-06-18 at 17:46 +0900, Masami Hiramatsu wrote: >>>>>> (2014/06/18 16:56), Michael Ellerman wrote: >>>>>>> On Fri, 2014-06-06 at 15:38 +0900, Masami Hiramatsu wrote: >>>>>>>> Ping? >>>>>>>> >>>>>>>> I guess this should go to 3.16 branch, shouldn't it? >>>>>>> >>>>>>>>> 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. >>>> >>>> >>>>> 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? > 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. > So, a kallsyms_lookup_size_offset() on both 'foo' and '.foo' will return > a hit. So, if we make sure we use the value of '.foo' (by using the > appropriate macros) we should be fine. > > And if so, how I can verify when initializing blacklist? >> (should I better use kallsyms_lookup() and kallsyms_lookup_name() for >> verification?) > One way to verify would be to make sure the symbol starts with '.' from > the result of the current kallsyms_lookup_size_offset() for PPC. OK, I'll do that as another enhancement, since the bug reported here will be fixed with our patch. Anyway, this patch itself should go into 3.16 tree to fix actual bug. Thanks, -- Masami HIRAMATSU Software Platform Research Dept. Linux Technology Research Center Hitachi, Ltd., Yokohama Research Laboratory E-mail: masami.hiramatsu.pt@hitachi.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/