[PATCH] x86/unwind/orc: Fix unwind for newly forked tasks

[PATCH] x86/unwind/orc: Fix unwind for newly forked tasks

[Zheng Yejian]

When arch_stack_walk_reliable() is called to unwind for newly forked
tasks, the return value is negative which means the call stack is
unreliable. This obviously does not meet expectations.

The root cause is that after commit 3aec4ecb3d1f ("x86: Rewrite
 ret_from_fork() in C"), the 'ret_addr' of newly forked task is changed
to 'ret_from_fork_asm' (see copy_thread()), then at the start of the
unwind, it is incorrectly interprets not as a "signal" one because
'ret_from_fork' is still used to determine the initial "signal" (see
__unwind_start()). Then the address gets incorrectly decremented in the
call to orc_find() (see unwind_next_frame()) and resulting in the
incorrect ORC data.

To fix it, check 'ret_from_fork_asm' rather than 'ret_from_fork' in
__unwind_start().

Fixes: 3aec4ecb3d1f ("x86: Rewrite ret_from_fork() in C")
Signed-off-by: Zheng Yejian <zhengyejian@huaweicloud.com>
---
 arch/x86/kernel/unwind_orc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/kernel/unwind_orc.c b/arch/x86/kernel/unwind_orc.c
index d00c28aaa5be..d4705a348a80 100644
--- a/arch/x86/kernel/unwind_orc.c
+++ b/arch/x86/kernel/unwind_orc.c
@@ -723,7 +723,7 @@ void __unwind_start(struct unwind_state *state, struct task_struct *task,
 		state->sp = task->thread.sp + sizeof(*frame);
 		state->bp = READ_ONCE_NOCHECK(frame->bp);
 		state->ip = READ_ONCE_NOCHECK(frame->ret_addr);
-		state->signal = (void *)state->ip == ret_from_fork;
+		state->signal = (void *)state->ip == ret_from_fork_asm;
 	}
 
 	if (get_stack_info((unsigned long *)state->sp, state->task,
-- 
2.25.1

Re: [PATCH] x86/unwind/orc: Fix unwind for newly forked tasks

[Josh Poimboeuf]

On Fri, Sep 13, 2024 at 10:45:01AM +0800, Zheng Yejian wrote:
> When arch_stack_walk_reliable() is called to unwind for newly forked
> tasks, the return value is negative which means the call stack is
> unreliable. This obviously does not meet expectations.
> 
> The root cause is that after commit 3aec4ecb3d1f ("x86: Rewrite
>  ret_from_fork() in C"), the 'ret_addr' of newly forked task is changed
> to 'ret_from_fork_asm' (see copy_thread()), then at the start of the
> unwind, it is incorrectly interprets not as a "signal" one because
> 'ret_from_fork' is still used to determine the initial "signal" (see
> __unwind_start()). Then the address gets incorrectly decremented in the
> call to orc_find() (see unwind_next_frame()) and resulting in the
> incorrect ORC data.
> 
> To fix it, check 'ret_from_fork_asm' rather than 'ret_from_fork' in
> __unwind_start().
> 
> Fixes: 3aec4ecb3d1f ("x86: Rewrite ret_from_fork() in C")
> Signed-off-by: Zheng Yejian <zhengyejian@huaweicloud.com>

Thanks!

Acked-by: Josh Poimboeuf <jpoimboe@kernel.org>

-- 
Josh

Re: [PATCH] x86/unwind/orc: Fix unwind for newly forked tasks

[Zheng Yejian]

On 2024/9/14 07:11, Josh Poimboeuf wrote:
> On Fri, Sep 13, 2024 at 10:45:01AM +0800, Zheng Yejian wrote:
>> When arch_stack_walk_reliable() is called to unwind for newly forked
>> tasks, the return value is negative which means the call stack is
>> unreliable. This obviously does not meet expectations.
>>
>> The root cause is that after commit 3aec4ecb3d1f ("x86: Rewrite
>>   ret_from_fork() in C"), the 'ret_addr' of newly forked task is changed
>> to 'ret_from_fork_asm' (see copy_thread()), then at the start of the
>> unwind, it is incorrectly interprets not as a "signal" one because
>> 'ret_from_fork' is still used to determine the initial "signal" (see
>> __unwind_start()). Then the address gets incorrectly decremented in the
>> call to orc_find() (see unwind_next_frame()) and resulting in the
>> incorrect ORC data.
>>
>> To fix it, check 'ret_from_fork_asm' rather than 'ret_from_fork' in
>> __unwind_start().
>>
>> Fixes: 3aec4ecb3d1f ("x86: Rewrite ret_from_fork() in C")
>> Signed-off-by: Zheng Yejian <zhengyejian@huaweicloud.com>
> 
> Thanks!
> 
> Acked-by: Josh Poimboeuf <jpoimboe@kernel.org>
> 

Hi, Josh, thanks for your ack!
Will this patch go into mainline soon?

-- 
Thanks,
Zheng Yejian

Re: [PATCH] x86/unwind/orc: Fix unwind for newly forked tasks

[Josh Poimboeuf]

On Fri, Oct 11, 2024 at 02:50:32PM +0800, Zheng Yejian wrote:
> On 2024/9/14 07:11, Josh Poimboeuf wrote:
> > On Fri, Sep 13, 2024 at 10:45:01AM +0800, Zheng Yejian wrote:
> > > When arch_stack_walk_reliable() is called to unwind for newly forked
> > > tasks, the return value is negative which means the call stack is
> > > unreliable. This obviously does not meet expectations.
> > > 
> > > The root cause is that after commit 3aec4ecb3d1f ("x86: Rewrite
> > >   ret_from_fork() in C"), the 'ret_addr' of newly forked task is changed
> > > to 'ret_from_fork_asm' (see copy_thread()), then at the start of the
> > > unwind, it is incorrectly interprets not as a "signal" one because
> > > 'ret_from_fork' is still used to determine the initial "signal" (see
> > > __unwind_start()). Then the address gets incorrectly decremented in the
> > > call to orc_find() (see unwind_next_frame()) and resulting in the
> > > incorrect ORC data.
> > > 
> > > To fix it, check 'ret_from_fork_asm' rather than 'ret_from_fork' in
> > > __unwind_start().
> > > 
> > > Fixes: 3aec4ecb3d1f ("x86: Rewrite ret_from_fork() in C")
> > > Signed-off-by: Zheng Yejian <zhengyejian@huaweicloud.com>
> > 
> > Thanks!
> > 
> > Acked-by: Josh Poimboeuf <jpoimboe@kernel.org>
> > 
> 
> Hi, Josh, thanks for your ack!
> Will this patch go into mainline soon?

Sorry about that, I'll go ahead and queue this up.

-- 
Josh

Re: [PATCH] x86/unwind/orc: Fix unwind for newly forked tasks

[Zheng Yejian]

On 2024/10/11 23:39, Josh Poimboeuf wrote:
> On Fri, Oct 11, 2024 at 02:50:32PM +0800, Zheng Yejian wrote:
>> On 2024/9/14 07:11, Josh Poimboeuf wrote:
>>> On Fri, Sep 13, 2024 at 10:45:01AM +0800, Zheng Yejian wrote:
>>>> When arch_stack_walk_reliable() is called to unwind for newly forked
>>>> tasks, the return value is negative which means the call stack is
>>>> unreliable. This obviously does not meet expectations.
>>>>
>>>> The root cause is that after commit 3aec4ecb3d1f ("x86: Rewrite
>>>>    ret_from_fork() in C"), the 'ret_addr' of newly forked task is changed
>>>> to 'ret_from_fork_asm' (see copy_thread()), then at the start of the
>>>> unwind, it is incorrectly interprets not as a "signal" one because
>>>> 'ret_from_fork' is still used to determine the initial "signal" (see
>>>> __unwind_start()). Then the address gets incorrectly decremented in the
>>>> call to orc_find() (see unwind_next_frame()) and resulting in the
>>>> incorrect ORC data.
>>>>
>>>> To fix it, check 'ret_from_fork_asm' rather than 'ret_from_fork' in
>>>> __unwind_start().
>>>>
>>>> Fixes: 3aec4ecb3d1f ("x86: Rewrite ret_from_fork() in C")
>>>> Signed-off-by: Zheng Yejian <zhengyejian@huaweicloud.com>
>>>
>>> Thanks!
>>>
>>> Acked-by: Josh Poimboeuf <jpoimboe@kernel.org>
>>>
>>
>> Hi, Josh, thanks for your ack!
>> Will this patch go into mainline soon?
> 
> Sorry about that, I'll go ahead and queue this up.
> 

Thanks!

Zheng Yejian