[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20210218175314.sdrkb3272bzezw3b@treble>
Date: Thu, 18 Feb 2021 11:53:14 -0600
From: Josh Poimboeuf <jpoimboe@...hat.com>
To: Peter Zijlstra <peterz@...radead.org>
Cc: linux-kernel@...r.kernel.org, linux-tip-commits@...r.kernel.org,
Miroslav Benes <mbenes@...e.cz>, x86@...nel.org
Subject: Re: [PATCH] objtool: Fix stack-swizzle for FRAME_POINTER=y
On Thu, Feb 18, 2021 at 05:21:31PM +0100, Peter Zijlstra wrote:
> On Wed, Feb 10, 2021 at 08:01:23PM -0000, tip-bot2 for Peter Zijlstra wrote:
> > objtool: Support stack-swizzle
>
> ---
> Subject: objtool: Fix stack-swizzle for FRAME_POINTER=y
> From: Peter Zijlstra <peterz@...radead.org>
> Date: Thu Feb 18 17:14:10 CET 2021
>
> When objtool encounters the stack-swizzle:
>
> mov %rsp, (%[tos])
> mov %[tos], %rsp
> ...
> pop %rsp
>
> Inside a FRAME_POINTER=y build, things go a little screwy because
> clearly we're not adjusting the cfa->base. This then results in the
> pop %rsp not being detected as a restore of cfa->base so it will turn
> into a regular POP and offset the stack, resulting in:
>
> kernel/softirq.o: warning: objtool: do_softirq()+0xdb: return with modified stack frame
>
> Therefore, have "mov %[tos], %rsp" act like a PUSH (it sorta is
> anyway) to balance the things out. We're not too concerned with the
> actual stack_size for frame-pointer builds, since we don't generate
> ORC data for them anyway.
>
> Fixes: aafeb14e9da2 ("objtool: Support stack-swizzle")
> Reported-by: kernel test robot <lkp@...el.com>
> Signed-off-by: Peter Zijlstra (Intel) <peterz@...radead.org>
Acked-by: Josh Poimboeuf <jpoimboe@...hat.com>
--
Josh
Powered by blists - more mailing lists