From: Tiezhu Yang <yangtiezhu@loongson.cn>
To: Jinyang He <hejinyang@loongson.cn>
Cc: Josh Poimboeuf <jpoimboe@kernel.org>,
Huacai Chen <chenhuacai@kernel.org>,
Xi Zhang <zhangxi@kylinos.cn>,
live-patching@vger.kernel.org, loongarch@lists.linux.dev,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v1 2/2] LoongArch: Return 0 for user tasks in arch_stack_walk_reliable()
Date: Thu, 11 Sep 2025 19:49:50 +0800 [thread overview]
Message-ID: <c3431ce4-0026-3a05-fa50-281cd34aba4e@loongson.cn> (raw)
In-Reply-To: <5e45a1a9-4ac3-56ee-1415-0b2128b4ed9a@loongson.cn>
On 2025/9/10 上午9:11, Jinyang He wrote:
> On 2025-09-09 19:31, Tiezhu Yang wrote:
>
>> When testing the kernel live patching with "modprobe livepatch-sample",
>> there is a timeout over 15 seconds from "starting patching transition"
>> to "patching complete", dmesg shows "unreliable stack" for user tasks
>> in debug mode. When executing "rmmod livepatch-sample", there exists
>> the similar issue.
...
>> @@ -57,9 +62,14 @@ int arch_stack_walk_reliable(stack_trace_consume_fn
>> consume_entry,
>> }
>> regs->regs[1] = 0;
>> regs->regs[22] = 0;
>> + regs->csr_prmd = task->thread.csr_prmd;
>> for (unwind_start(&state, task, regs);
>> !unwind_done(&state) && !unwind_error(&state);
>> unwind_next_frame(&state)) {
>> + /* Success path for user tasks */
>> + if (user_mode(regs))
>> + return 0;
>> +
>> addr = unwind_get_return_address(&state);
>> /*
> Hi, Tiezhu,
>
> We update stack info by get_stack_info when meet ORC_TYPE_REGS in
> unwind_next_frame. And in arch_stack_walk(_reliable), we always
> do unwind_done before unwind_next_frame. So is there anything
> error in get_stack_info which causing regs is user_mode while
> stack is not STACK_TYPE_UNKNOWN?
When testing the kernel live patching, the error code path in
unwind_next_frame() is:
switch (orc->fp_reg) {
case ORC_REG_PREV_SP:
p = (unsigned long *)(state->sp + orc->fp_offset);
if (!stack_access_ok(state, (unsigned long)p,
sizeof(unsigned long)))
goto err;
for this case, get_stack_info() does not return 0 due to in_task_stack()
is not true, then goto error, state->stack_info.type = STACK_TYPE_UNKNOWN
and state->error = true. In arch_stack_walk_reliable(), the loop will be
break and it returns -EINVAL, thus causing unreliable stack.
Maybe it can check whether the task is in userspace and set
state->stack_info.type = STACK_TYPE_UNKNOWN in get_stack_info(),
but I think no need to do that because it has similar effect with
this patch.
Thanks,
Tiezhu
next prev parent reply other threads:[~2025-09-11 11:49 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-09 11:31 [PATCH v1 0/2] Debug and fix livepatch issues on LoongArch Tiezhu Yang
2025-09-09 11:31 ` [PATCH v1 1/2] livepatch: Add config LIVEPATCH_DEBUG to get debug information Tiezhu Yang
2025-09-11 13:50 ` Miroslav Benes
2025-09-12 2:26 ` Tiezhu Yang
2025-09-12 7:14 ` Miroslav Benes
2025-09-09 11:31 ` [PATCH v1 2/2] LoongArch: Return 0 for user tasks in arch_stack_walk_reliable() Tiezhu Yang
2025-09-10 1:11 ` Jinyang He
2025-09-11 11:49 ` Tiezhu Yang [this message]
2025-09-12 1:55 ` Jinyang He
2025-09-15 8:54 ` Tiezhu Yang
2025-09-11 13:44 ` Miroslav Benes
2025-09-15 8:48 ` Tiezhu Yang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=c3431ce4-0026-3a05-fa50-281cd34aba4e@loongson.cn \
--to=yangtiezhu@loongson.cn \
--cc=chenhuacai@kernel.org \
--cc=hejinyang@loongson.cn \
--cc=jpoimboe@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=live-patching@vger.kernel.org \
--cc=loongarch@lists.linux.dev \
--cc=zhangxi@kylinos.cn \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox