Re: [RFT PATCH -next v3] [BUGFIX] kprobes: Fix "Failed to find blacklist" error on ia64 and ppc64
(2014/06/20 9:37), Michael Ellerman wrote: > On Thu, 2014-06-19 at 20:20 +0900, Masami Hiramatsu wrote: >> (2014/06/19 20:01), Masami Hiramatsu wrote: >> >>> 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...@hitachi.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Re: Re: [RFT PATCH -next v3] [BUGFIX] kprobes: Fix "Failed to find blacklist" error on ia64 and ppc64
On Thu, 2014-06-19 at 20:20 +0900, Masami Hiramatsu wrote: > (2014/06/19 20:01), Masami Hiramatsu wrote: > > > 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". On 64-bit, ABIv2, "foo" points to the text in ".text". There are no dot symbols. cheers -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Re: Re: [RFT PATCH -next v3] [BUGFIX] kprobes: Fix "Failed to find blacklist" error on ia64 and ppc64
(2014/06/19 20:01), Masami Hiramatsu wrote: > 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. Thank you, -- Masami HIRAMATSU Software Platform Research Dept. Linux Technology Research Center Hitachi, Ltd., Yokohama Research Laboratory E-mail: masami.hiramatsu...@hitachi.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Re: [RFT PATCH -next v3] [BUGFIX] kprobes: Fix "Failed to find blacklist" error on ia64 and ppc64
(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...@hitachi.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFT PATCH -next v3] [BUGFIX] kprobes: Fix "Failed to find blacklist" error on ia64 and ppc64
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. 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. Thanks Suzuki > > 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 >> >> >>> >>> Thank you, >>> -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Re: [RFT PATCH -next v3] [BUGFIX] kprobes: Fix "Failed to find blacklist" error on ia64 and ppc64
(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? 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 > > >> >> Thank you, >> -- Masami HIRAMATSU Software Platform Research Dept. Linux Technology Research Center Hitachi, Ltd., Yokohama Research Laboratory E-mail: masami.hiramatsu...@hitachi.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFT PATCH -next v3] [BUGFIX] kprobes: Fix "Failed to find blacklist" error on ia64 and ppc64
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 : 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 > > Thank you, > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFT PATCH -next v3] [BUGFIX] kprobes: Fix Failed to find blacklist error on ia64 and ppc64
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 : 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 Thank you, -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Re: [RFT PATCH -next v3] [BUGFIX] kprobes: Fix Failed to find blacklist error on ia64 and ppc64
(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? 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 Thank you, -- Masami HIRAMATSU Software Platform Research Dept. Linux Technology Research Center Hitachi, Ltd., Yokohama Research Laboratory E-mail: masami.hiramatsu...@hitachi.com -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFT PATCH -next v3] [BUGFIX] kprobes: Fix Failed to find blacklist error on ia64 and ppc64
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. 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. Thanks Suzuki 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 Thank you, -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Re: [RFT PATCH -next v3] [BUGFIX] kprobes: Fix Failed to find blacklist error on ia64 and ppc64
(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...@hitachi.com -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Re: Re: [RFT PATCH -next v3] [BUGFIX] kprobes: Fix Failed to find blacklist error on ia64 and ppc64
(2014/06/19 20:01), Masami Hiramatsu wrote: 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. Thank you, -- Masami HIRAMATSU Software Platform Research Dept. Linux Technology Research Center Hitachi, Ltd., Yokohama Research Laboratory E-mail: masami.hiramatsu...@hitachi.com -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Re: Re: [RFT PATCH -next v3] [BUGFIX] kprobes: Fix Failed to find blacklist error on ia64 and ppc64
On Thu, 2014-06-19 at 20:20 +0900, Masami Hiramatsu wrote: (2014/06/19 20:01), Masami Hiramatsu wrote: 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. On 64-bit, ABIv2, foo points to the text in .text. There are no dot symbols. cheers -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFT PATCH -next v3] [BUGFIX] kprobes: Fix Failed to find blacklist error on ia64 and ppc64
(2014/06/20 9:37), Michael Ellerman wrote: On Thu, 2014-06-19 at 20:20 +0900, Masami Hiramatsu wrote: (2014/06/19 20:01), Masami Hiramatsu wrote: 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...@hitachi.com -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFT PATCH -next v3] [BUGFIX] kprobes: Fix "Failed to find blacklist" error on ia64 and ppc64
(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. Thank you, -- Masami HIRAMATSU Software Platform Research Dept. Linux Technology Research Center Hitachi, Ltd., Yokohama Research Laboratory E-mail: masami.hiramatsu...@hitachi.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Re: [RFT PATCH -next v3] [BUGFIX] kprobes: Fix "Failed to find blacklist" error on ia64 and ppc64
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. 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. cheers -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Re: [RFT PATCH -next v3] [BUGFIX] kprobes: Fix "Failed to find blacklist" error on ia64 and ppc64
(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? Thank you, -- Masami HIRAMATSU Software Platform Research Dept. Linux Technology Research Center Hitachi, Ltd., Yokohama Research Laboratory E-mail: masami.hiramatsu...@hitachi.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFT PATCH -next v3] [BUGFIX] kprobes: Fix "Failed to find blacklist" error on ia64 and ppc64
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? cheers -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFT PATCH -next v3] [BUGFIX] kprobes: Fix Failed to find blacklist error on ia64 and ppc64
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? cheers -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Re: [RFT PATCH -next v3] [BUGFIX] kprobes: Fix Failed to find blacklist error on ia64 and ppc64
(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? Thank you, -- Masami HIRAMATSU Software Platform Research Dept. Linux Technology Research Center Hitachi, Ltd., Yokohama Research Laboratory E-mail: masami.hiramatsu...@hitachi.com -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Re: [RFT PATCH -next v3] [BUGFIX] kprobes: Fix Failed to find blacklist error on ia64 and ppc64
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. 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. cheers -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFT PATCH -next v3] [BUGFIX] kprobes: Fix Failed to find blacklist error on ia64 and ppc64
(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. Thank you, -- Masami HIRAMATSU Software Platform Research Dept. Linux Technology Research Center Hitachi, Ltd., Yokohama Research Laboratory E-mail: masami.hiramatsu...@hitachi.com -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFT PATCH -next v3] [BUGFIX] kprobes: Fix "Failed to find blacklist" error on ia64 and ppc64
On Thu, Jun 5, 2014 at 11:38 PM, Masami Hiramatsu wrote: > Ping? > > I guess this should go to 3.16 branch, shouldn't it? > > (2014/05/30 12:18), Masami Hiramatsu wrote: >> On ia64 and ppc64, the function pointer does not point the >> entry address of the function, but the address of function >> discriptor (which contains the entry address and misc >> data.) Since the kprobes passes the function pointer stored >> by NOKPROBE_SYMBOL() to kallsyms_lookup_size_offset() for >> initalizing its blacklist, it fails and reports many errors >> as below. >> >> Failed to find blacklist 000101316830 Yes please ... just found this problem on ia64 in mainline and was happy to see this fix for it. Tested-by: Tony Luck -Tony -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFT PATCH -next v3] [BUGFIX] kprobes: Fix Failed to find blacklist error on ia64 and ppc64
On Thu, Jun 5, 2014 at 11:38 PM, Masami Hiramatsu masami.hiramatsu...@hitachi.com wrote: Ping? I guess this should go to 3.16 branch, shouldn't it? (2014/05/30 12:18), Masami Hiramatsu wrote: On ia64 and ppc64, the function pointer does not point the entry address of the function, but the address of function discriptor (which contains the entry address and misc data.) Since the kprobes passes the function pointer stored by NOKPROBE_SYMBOL() to kallsyms_lookup_size_offset() for initalizing its blacklist, it fails and reports many errors as below. Failed to find blacklist 000101316830 Yes please ... just found this problem on ia64 in mainline and was happy to see this fix for it. Tested-by: Tony Luck tony.l...@intel.com -Tony -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFT PATCH -next v3] [BUGFIX] kprobes: Fix "Failed to find blacklist" error on ia64 and ppc64
Ping? I guess this should go to 3.16 branch, shouldn't it? (2014/05/30 12:18), Masami Hiramatsu wrote: > On ia64 and ppc64, the function pointer does not point the > entry address of the function, but the address of function > discriptor (which contains the entry address and misc > data.) Since the kprobes passes the function pointer stored > by NOKPROBE_SYMBOL() to kallsyms_lookup_size_offset() for > initalizing its blacklist, it fails and reports many errors > as below. > > Failed to find blacklist 000101316830 > Failed to find blacklist 0001013000f0a000 > Failed to find blacklist 000101315f70a000 > Failed to find blacklist 000101324c80a000 > Failed to find blacklist 0001013063f0a000 > Failed to find blacklist 000101327800a000 > Failed to find blacklist 0001013277f0a000 > Failed to find blacklist 000101315a70a000 > Failed to find blacklist 0001013277e0a000 > Failed to find blacklist 000101305a20a000 > Failed to find blacklist 0001013277d0a000 > Failed to find blacklist 00010130bdc0a000 > Failed to find blacklist 00010130dc20a000 > Failed to find blacklist 000101309a00a000 > Failed to find blacklist 0001013277c0a000 > Failed to find blacklist 0001013277b0a000 > Failed to find blacklist 0001013277a0a000 > Failed to find blacklist 000101327790a000 > Failed to find blacklist 000101303140a000 > Failed to find blacklist 0001013a3280a000 > > To fix this bug, this introduces function_entry() macro to > retrieve the entry address from the given function pointer, > and uses for kallsyms_lookup_size_offset() while initializing > blacklist. > > Changes in v3: > - Fix a bug to get blacklist address based on function entry >instead of function descriptor. (Suzuki's work, Thanks!) > > Changes in V2: > - Use function_entry() macro when lookin up symbols instead >of storing it. > - Update for the latest -next. > > Signed-off-by: Masami Hiramatsu > Signed-off-by: Suzuki K. Poulose > Reported-by: Tony Luck > Cc: Suzuki K. Poulose > Cc: Tony Luck > Cc: Fenghua Yu > Cc: Benjamin Herrenschmidt > Cc: Paul Mackerras > Cc: Ananth N Mavinakayanahalli > Cc: Kevin Hao > Cc: linux-i...@vger.kernel.org > Cc: linux-kernel@vger.kernel.org > Cc: linuxppc-...@lists.ozlabs.org > --- > arch/ia64/include/asm/types.h|2 ++ > arch/powerpc/include/asm/types.h | 11 +++ > include/linux/types.h|4 > kernel/kprobes.c | 11 +++ > 4 files changed, 24 insertions(+), 4 deletions(-) > > diff --git a/arch/ia64/include/asm/types.h b/arch/ia64/include/asm/types.h > index 4c351b1..95279dd 100644 > --- a/arch/ia64/include/asm/types.h > +++ b/arch/ia64/include/asm/types.h > @@ -27,5 +27,7 @@ struct fnptr { > unsigned long gp; > }; > > +#define function_entry(fn) (((struct fnptr *)(fn))->ip) > + > #endif /* !__ASSEMBLY__ */ > #endif /* _ASM_IA64_TYPES_H */ > 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 > + > #endif /* __ASSEMBLY__ */ > > #endif /* _ASM_POWERPC_TYPES_H */ > diff --git a/include/linux/types.h b/include/linux/types.h > index a0bb704..3b95369 100644 > --- a/include/linux/types.h > +++ b/include/linux/types.h > @@ -213,5 +213,9 @@ struct callback_head { > }; > #define rcu_head callback_head > > +#ifndef function_entry > +#define function_entry(fn) ((unsigned long)(fn)) > +#endif > + > #endif /* __ASSEMBLY__ */ > #endif /* _LINUX_TYPES_H */ > diff --git a/kernel/kprobes.c b/kernel/kprobes.c > index 2ac9f13..3f2d6d4 100644 > --- a/kernel/kprobes.c > +++ b/kernel/kprobes.c > @@ -32,6 +32,7 @@ > *added function-return probes. > */ > #include > +#include > #include > #include > #include > @@ -2042,16 +2043,18 @@ static int __init populate_kprobe_blacklist(unsigned > long *start, > unsigned long offset = 0, size = 0; > > for (iter = start; iter < end; iter++) { > - if (!kallsyms_lookup_size_offset(*iter, , )) { > - pr_err("Failed to find blacklist %p\n", (void *)*iter); > + unsigned long entry = function_entry(*iter); > + if (!kallsyms_lookup_size_offset(entry, , )) { > + pr_err("Failed to find blacklist at %p\n", > +(void *)entry); > continue; > } > > ent =
Re: [RFT PATCH -next v3] [BUGFIX] kprobes: Fix Failed to find blacklist error on ia64 and ppc64
Ping? I guess this should go to 3.16 branch, shouldn't it? (2014/05/30 12:18), Masami Hiramatsu wrote: On ia64 and ppc64, the function pointer does not point the entry address of the function, but the address of function discriptor (which contains the entry address and misc data.) Since the kprobes passes the function pointer stored by NOKPROBE_SYMBOL() to kallsyms_lookup_size_offset() for initalizing its blacklist, it fails and reports many errors as below. Failed to find blacklist 000101316830 Failed to find blacklist 0001013000f0a000 Failed to find blacklist 000101315f70a000 Failed to find blacklist 000101324c80a000 Failed to find blacklist 0001013063f0a000 Failed to find blacklist 000101327800a000 Failed to find blacklist 0001013277f0a000 Failed to find blacklist 000101315a70a000 Failed to find blacklist 0001013277e0a000 Failed to find blacklist 000101305a20a000 Failed to find blacklist 0001013277d0a000 Failed to find blacklist 00010130bdc0a000 Failed to find blacklist 00010130dc20a000 Failed to find blacklist 000101309a00a000 Failed to find blacklist 0001013277c0a000 Failed to find blacklist 0001013277b0a000 Failed to find blacklist 0001013277a0a000 Failed to find blacklist 000101327790a000 Failed to find blacklist 000101303140a000 Failed to find blacklist 0001013a3280a000 To fix this bug, this introduces function_entry() macro to retrieve the entry address from the given function pointer, and uses for kallsyms_lookup_size_offset() while initializing blacklist. Changes in v3: - Fix a bug to get blacklist address based on function entry instead of function descriptor. (Suzuki's work, Thanks!) Changes in V2: - Use function_entry() macro when lookin up symbols instead of storing it. - Update for the latest -next. Signed-off-by: Masami Hiramatsu masami.hiramatsu...@hitachi.com Signed-off-by: Suzuki K. Poulose suz...@in.ibm.com Reported-by: Tony Luck tony.l...@gmail.com Cc: Suzuki K. Poulose suz...@in.ibm.com Cc: Tony Luck tony.l...@intel.com Cc: Fenghua Yu fenghua...@intel.com Cc: Benjamin Herrenschmidt b...@kernel.crashing.org Cc: Paul Mackerras pau...@samba.org Cc: Ananth N Mavinakayanahalli ana...@in.ibm.com Cc: Kevin Hao haoke...@gmail.com Cc: linux-i...@vger.kernel.org Cc: linux-kernel@vger.kernel.org Cc: linuxppc-...@lists.ozlabs.org --- arch/ia64/include/asm/types.h|2 ++ arch/powerpc/include/asm/types.h | 11 +++ include/linux/types.h|4 kernel/kprobes.c | 11 +++ 4 files changed, 24 insertions(+), 4 deletions(-) diff --git a/arch/ia64/include/asm/types.h b/arch/ia64/include/asm/types.h index 4c351b1..95279dd 100644 --- a/arch/ia64/include/asm/types.h +++ b/arch/ia64/include/asm/types.h @@ -27,5 +27,7 @@ struct fnptr { unsigned long gp; }; +#define function_entry(fn) (((struct fnptr *)(fn))-ip) + #endif /* !__ASSEMBLY__ */ #endif /* _ASM_IA64_TYPES_H */ 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 + #endif /* __ASSEMBLY__ */ #endif /* _ASM_POWERPC_TYPES_H */ diff --git a/include/linux/types.h b/include/linux/types.h index a0bb704..3b95369 100644 --- a/include/linux/types.h +++ b/include/linux/types.h @@ -213,5 +213,9 @@ struct callback_head { }; #define rcu_head callback_head +#ifndef function_entry +#define function_entry(fn) ((unsigned long)(fn)) +#endif + #endif /* __ASSEMBLY__ */ #endif /* _LINUX_TYPES_H */ diff --git a/kernel/kprobes.c b/kernel/kprobes.c index 2ac9f13..3f2d6d4 100644 --- a/kernel/kprobes.c +++ b/kernel/kprobes.c @@ -32,6 +32,7 @@ * prasa...@in.ibm.com added function-return probes. */ #include linux/kprobes.h +#include linux/types.h #include linux/hash.h #include linux/init.h #include linux/slab.h @@ -2042,16 +2043,18 @@ static int __init populate_kprobe_blacklist(unsigned long *start, unsigned long offset = 0, size = 0; for (iter = start; iter end; iter++) { - if (!kallsyms_lookup_size_offset(*iter, size, offset)) { - pr_err(Failed to find blacklist %p\n, (void *)*iter); + unsigned long entry = function_entry(*iter); + if (!kallsyms_lookup_size_offset(entry, size, offset)) { + pr_err(Failed to find
[RFT PATCH -next v3] [BUGFIX] kprobes: Fix "Failed to find blacklist" error on ia64 and ppc64
On ia64 and ppc64, the function pointer does not point the entry address of the function, but the address of function discriptor (which contains the entry address and misc data.) Since the kprobes passes the function pointer stored by NOKPROBE_SYMBOL() to kallsyms_lookup_size_offset() for initalizing its blacklist, it fails and reports many errors as below. Failed to find blacklist 000101316830 Failed to find blacklist 0001013000f0a000 Failed to find blacklist 000101315f70a000 Failed to find blacklist 000101324c80a000 Failed to find blacklist 0001013063f0a000 Failed to find blacklist 000101327800a000 Failed to find blacklist 0001013277f0a000 Failed to find blacklist 000101315a70a000 Failed to find blacklist 0001013277e0a000 Failed to find blacklist 000101305a20a000 Failed to find blacklist 0001013277d0a000 Failed to find blacklist 00010130bdc0a000 Failed to find blacklist 00010130dc20a000 Failed to find blacklist 000101309a00a000 Failed to find blacklist 0001013277c0a000 Failed to find blacklist 0001013277b0a000 Failed to find blacklist 0001013277a0a000 Failed to find blacklist 000101327790a000 Failed to find blacklist 000101303140a000 Failed to find blacklist 0001013a3280a000 To fix this bug, this introduces function_entry() macro to retrieve the entry address from the given function pointer, and uses for kallsyms_lookup_size_offset() while initializing blacklist. Changes in v3: - Fix a bug to get blacklist address based on function entry instead of function descriptor. (Suzuki's work, Thanks!) Changes in V2: - Use function_entry() macro when lookin up symbols instead of storing it. - Update for the latest -next. Signed-off-by: Masami Hiramatsu Signed-off-by: Suzuki K. Poulose Reported-by: Tony Luck Cc: Suzuki K. Poulose Cc: Tony Luck Cc: Fenghua Yu Cc: Benjamin Herrenschmidt Cc: Paul Mackerras Cc: Ananth N Mavinakayanahalli Cc: Kevin Hao Cc: linux-i...@vger.kernel.org Cc: linux-kernel@vger.kernel.org Cc: linuxppc-...@lists.ozlabs.org --- arch/ia64/include/asm/types.h|2 ++ arch/powerpc/include/asm/types.h | 11 +++ include/linux/types.h|4 kernel/kprobes.c | 11 +++ 4 files changed, 24 insertions(+), 4 deletions(-) diff --git a/arch/ia64/include/asm/types.h b/arch/ia64/include/asm/types.h index 4c351b1..95279dd 100644 --- a/arch/ia64/include/asm/types.h +++ b/arch/ia64/include/asm/types.h @@ -27,5 +27,7 @@ struct fnptr { unsigned long gp; }; +#define function_entry(fn) (((struct fnptr *)(fn))->ip) + #endif /* !__ASSEMBLY__ */ #endif /* _ASM_IA64_TYPES_H */ 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 + #endif /* __ASSEMBLY__ */ #endif /* _ASM_POWERPC_TYPES_H */ diff --git a/include/linux/types.h b/include/linux/types.h index a0bb704..3b95369 100644 --- a/include/linux/types.h +++ b/include/linux/types.h @@ -213,5 +213,9 @@ struct callback_head { }; #define rcu_head callback_head +#ifndef function_entry +#define function_entry(fn) ((unsigned long)(fn)) +#endif + #endif /* __ASSEMBLY__ */ #endif /* _LINUX_TYPES_H */ diff --git a/kernel/kprobes.c b/kernel/kprobes.c index 2ac9f13..3f2d6d4 100644 --- a/kernel/kprobes.c +++ b/kernel/kprobes.c @@ -32,6 +32,7 @@ * added function-return probes. */ #include +#include #include #include #include @@ -2042,16 +2043,18 @@ static int __init populate_kprobe_blacklist(unsigned long *start, unsigned long offset = 0, size = 0; for (iter = start; iter < end; iter++) { - if (!kallsyms_lookup_size_offset(*iter, , )) { - pr_err("Failed to find blacklist %p\n", (void *)*iter); + unsigned long entry = function_entry(*iter); + if (!kallsyms_lookup_size_offset(entry, , )) { + pr_err("Failed to find blacklist at %p\n", + (void *)entry); continue; } ent = kmalloc(sizeof(*ent), GFP_KERNEL); if (!ent) return -ENOMEM; - ent->start_addr = *iter; - ent->end_addr = *iter + size; + ent->start_addr = entry; + ent->end_addr = entry + size; INIT_LIST_HEAD(>list); list_add_tail(>list, _blacklist);
[RFT PATCH -next v3] [BUGFIX] kprobes: Fix Failed to find blacklist error on ia64 and ppc64
On ia64 and ppc64, the function pointer does not point the entry address of the function, but the address of function discriptor (which contains the entry address and misc data.) Since the kprobes passes the function pointer stored by NOKPROBE_SYMBOL() to kallsyms_lookup_size_offset() for initalizing its blacklist, it fails and reports many errors as below. Failed to find blacklist 000101316830 Failed to find blacklist 0001013000f0a000 Failed to find blacklist 000101315f70a000 Failed to find blacklist 000101324c80a000 Failed to find blacklist 0001013063f0a000 Failed to find blacklist 000101327800a000 Failed to find blacklist 0001013277f0a000 Failed to find blacklist 000101315a70a000 Failed to find blacklist 0001013277e0a000 Failed to find blacklist 000101305a20a000 Failed to find blacklist 0001013277d0a000 Failed to find blacklist 00010130bdc0a000 Failed to find blacklist 00010130dc20a000 Failed to find blacklist 000101309a00a000 Failed to find blacklist 0001013277c0a000 Failed to find blacklist 0001013277b0a000 Failed to find blacklist 0001013277a0a000 Failed to find blacklist 000101327790a000 Failed to find blacklist 000101303140a000 Failed to find blacklist 0001013a3280a000 To fix this bug, this introduces function_entry() macro to retrieve the entry address from the given function pointer, and uses for kallsyms_lookup_size_offset() while initializing blacklist. Changes in v3: - Fix a bug to get blacklist address based on function entry instead of function descriptor. (Suzuki's work, Thanks!) Changes in V2: - Use function_entry() macro when lookin up symbols instead of storing it. - Update for the latest -next. Signed-off-by: Masami Hiramatsu masami.hiramatsu...@hitachi.com Signed-off-by: Suzuki K. Poulose suz...@in.ibm.com Reported-by: Tony Luck tony.l...@gmail.com Cc: Suzuki K. Poulose suz...@in.ibm.com Cc: Tony Luck tony.l...@intel.com Cc: Fenghua Yu fenghua...@intel.com Cc: Benjamin Herrenschmidt b...@kernel.crashing.org Cc: Paul Mackerras pau...@samba.org Cc: Ananth N Mavinakayanahalli ana...@in.ibm.com Cc: Kevin Hao haoke...@gmail.com Cc: linux-i...@vger.kernel.org Cc: linux-kernel@vger.kernel.org Cc: linuxppc-...@lists.ozlabs.org --- arch/ia64/include/asm/types.h|2 ++ arch/powerpc/include/asm/types.h | 11 +++ include/linux/types.h|4 kernel/kprobes.c | 11 +++ 4 files changed, 24 insertions(+), 4 deletions(-) diff --git a/arch/ia64/include/asm/types.h b/arch/ia64/include/asm/types.h index 4c351b1..95279dd 100644 --- a/arch/ia64/include/asm/types.h +++ b/arch/ia64/include/asm/types.h @@ -27,5 +27,7 @@ struct fnptr { unsigned long gp; }; +#define function_entry(fn) (((struct fnptr *)(fn))-ip) + #endif /* !__ASSEMBLY__ */ #endif /* _ASM_IA64_TYPES_H */ 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 + #endif /* __ASSEMBLY__ */ #endif /* _ASM_POWERPC_TYPES_H */ diff --git a/include/linux/types.h b/include/linux/types.h index a0bb704..3b95369 100644 --- a/include/linux/types.h +++ b/include/linux/types.h @@ -213,5 +213,9 @@ struct callback_head { }; #define rcu_head callback_head +#ifndef function_entry +#define function_entry(fn) ((unsigned long)(fn)) +#endif + #endif /* __ASSEMBLY__ */ #endif /* _LINUX_TYPES_H */ diff --git a/kernel/kprobes.c b/kernel/kprobes.c index 2ac9f13..3f2d6d4 100644 --- a/kernel/kprobes.c +++ b/kernel/kprobes.c @@ -32,6 +32,7 @@ * prasa...@in.ibm.com added function-return probes. */ #include linux/kprobes.h +#include linux/types.h #include linux/hash.h #include linux/init.h #include linux/slab.h @@ -2042,16 +2043,18 @@ static int __init populate_kprobe_blacklist(unsigned long *start, unsigned long offset = 0, size = 0; for (iter = start; iter end; iter++) { - if (!kallsyms_lookup_size_offset(*iter, size, offset)) { - pr_err(Failed to find blacklist %p\n, (void *)*iter); + unsigned long entry = function_entry(*iter); + if (!kallsyms_lookup_size_offset(entry, size, offset)) { + pr_err(Failed to find blacklist at %p\n, + (void *)entry); continue; } ent = kmalloc(sizeof(*ent), GFP_KERNEL); if (!ent)