On Tue, Jan 12, 2016 at 01:41:58PM +0100, Borislav Petkov wrote: > On Fri, Dec 18, 2015 at 06:39:35AM -0600, Josh Poimboeuf wrote: > > rwsem.S has several callable non-leaf functions which don't honor > > CONFIG_FRAME_POINTER, which can result in bad stack traces. > > > > Create stack frames for them when CONFIG_FRAME_POINTER is enabled. > > > > Signed-off-by: Josh Poimboeuf <jpoimboe@xxxxxxxxxx> > > --- > > arch/x86/lib/rwsem.S | 11 ++++++++++- > > 1 file changed, 10 insertions(+), 1 deletion(-) > > > > diff --git a/arch/x86/lib/rwsem.S b/arch/x86/lib/rwsem.S > > index 40027db..be110ef 100644 > > --- a/arch/x86/lib/rwsem.S > > +++ b/arch/x86/lib/rwsem.S > > @@ -15,6 +15,7 @@ > > > > #include <linux/linkage.h> > > #include <asm/alternative-asm.h> > > +#include <asm/frame.h> > > > > #define __ASM_HALF_REG(reg) __ASM_SEL(reg, e##reg) > > #define __ASM_HALF_SIZE(inst) __ASM_SEL(inst##w, inst##l) > > @@ -84,24 +85,29 @@ > > > > /* Fix up special calling conventions */ > > ENTRY(call_rwsem_down_read_failed) > > + FRAME_BEGIN > > Remind me again, please, why aren't we hiding those > FRAME_BEGIN/FRAME_END macros in the ENTRY/ENDPROC ones? Ingo made a similar suggestion a while back: https://lkml.kernel.org/r/20150717194307.GA26757@xxxxxxxxx But the frame stuff can't be folded into ENTRY/ENDPROC because we don't need to create a stack frame for *all* functions, but rather only for non-leaf functions. So then we considered something like: FUNCTION_ENTRY(func) FUNCTION_RETURN(func) for non-leaf functions, and: LEAF_FUNCTION_ENTRY(func) LEAF_FUNCTION_RETURN(func) for leaf functions. But that was too inflexible for the case where a function ends with a jump instead of a return. > > save_common_regs > > __ASM_SIZE(push,) %__ASM_REG(dx) > > movq %rax,%rdi > > call rwsem_down_read_failed > > __ASM_SIZE(pop,) %__ASM_REG(dx) > > restore_common_regs > > + FRAME_END > > ret > > ENDPROC(call_rwsem_down_read_failed) -- Josh -- To unsubscribe from this list: send the line "unsubscribe live-patching" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
