lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Sat, 15 Mar 2014 01:15:06 +0900 From: AKASHI Takahiro <takahiro.akashi@...aro.org> To: Will Deacon <will.deacon@....com> CC: "rostedt@...dmis.org" <rostedt@...dmis.org>, "fweisbec@...il.com" <fweisbec@...il.com>, "mingo@...hat.com" <mingo@...hat.com>, Catalin Marinas <Catalin.Marinas@....com>, "tim.bird@...ymobile.com" <tim.bird@...ymobile.com>, "gkulkarni@...iumnetworks.com" <gkulkarni@...iumnetworks.com>, "dsaxena@...aro.org" <dsaxena@...aro.org>, "arndb@...db.de" <arndb@...db.de>, "linux-arm-kernel@...ts.infradead.org" <linux-arm-kernel@...ts.infradead.org>, "linaro-kernel@...ts.linaro.org" <linaro-kernel@...ts.linaro.org>, "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org> Subject: Re: [PATCH v6 6/7] arm64: ftrace: Add CALLER_ADDRx macros On 03/14/2014 07:09 PM, Will Deacon wrote: > On Fri, Mar 14, 2014 at 03:00:14AM +0000, AKASHI Takahiro wrote: >> On 03/14/2014 12:54 AM, Will Deacon wrote: >>> On Thu, Mar 13, 2014 at 10:13:49AM +0000, AKASHI Takahiro wrote: >>>> CALLER_ADDRx returns caller's address at specified level in call stacks. >>>> They are used for several tracers like irqsoff and preemptoff. >>>> Strange to say, however, they are refered even without FTRACE. >>>> >>>> Please note that this implementation assumes that we have frame pointers. >>>> (which means kernel should be compiled with -fno-omit-frame-pointer.) >>> >>> How do you ensure that -fno-omit-frame-pointer is passed? >> >> arm64 selects ARCH_WANT_FRAME_POINTERS, then FRAME_POINTER is on (lib/Kconfig.debug) >> and so -fno-omit-frame-pointer is appended (${TOP}/Makefile). >> (stacktrace.c also assumes FRAME_POINTER.) >> >> Do you think I should remove the comment above? > > Yes please, it sounds like everything is taken care of automatically, so > there's no need to scare people in the commit message! OK, I will do so. Thanks, -Takahiro AKASHI >>>> diff --git a/arch/arm64/include/asm/ftrace.h b/arch/arm64/include/asm/ftrace.h >>>> index ed5c448..c44c4b1 100644 >>>> --- a/arch/arm64/include/asm/ftrace.h >>>> +++ b/arch/arm64/include/asm/ftrace.h >>>> @@ -18,6 +18,7 @@ >>>> >>>> #ifndef __ASSEMBLY__ >>>> extern void _mcount(unsigned long); >>>> +extern void *return_address(unsigned int); >>>> >>>> struct dyn_arch_ftrace { >>>> /* No extra data needed for arm64 */ >>>> @@ -33,6 +34,16 @@ static inline unsigned long ftrace_call_adjust(unsigned long addr) >>>> */ >>>> return addr; >>>> } >>>> -#endif /* __ASSEMBLY__ */ >>>> + >>>> +#define HAVE_ARCH_CALLER_ADDR >>>> + >>>> +#define CALLER_ADDR0 ((unsigned long)__builtin_return_address(0)) >>>> +#define CALLER_ADDR1 ((unsigned long)return_address(1)) >>>> +#define CALLER_ADDR2 ((unsigned long)return_address(2)) >>>> +#define CALLER_ADDR3 ((unsigned long)return_address(3)) >>>> +#define CALLER_ADDR4 ((unsigned long)return_address(4)) >>>> +#define CALLER_ADDR5 ((unsigned long)return_address(5)) >>>> +#define CALLER_ADDR6 ((unsigned long)return_address(6)) >>> >>> Could we change the core definitions of these macros (in linux/ftrace.h) to >>> use return_address, then provide an overridable version of return_address >>> that defaults to __builtin_return_address, instead of copy-pasting this >>> sequence? >> >> I think I understand what you mean, and will try to post a separate RFC, >> but I also want to hold off this change on this patch since such a change >> may raise a small controversy from other archs' maintainers. > > I don't see anything controversial here, but ok. Steve already posted > something you can get started with. > > Will > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists