[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <2b3235b7-87a5-9146-9f31-4668dda207b2@loongson.cn>
Date: Mon, 15 Sep 2025 16:48:18 +0800
From: Tiezhu Yang <yangtiezhu@...ngson.cn>
To: Miroslav Benes <mbenes@...e.cz>
Cc: Josh Poimboeuf <jpoimboe@...nel.org>, Huacai Chen
<chenhuacai@...nel.org>, Xi Zhang <zhangxi@...inos.cn>,
live-patching@...r.kernel.org, loongarch@...ts.linux.dev,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH v1 2/2] LoongArch: Return 0 for user tasks in
arch_stack_walk_reliable()
On 2025/9/11 下午9:44, Miroslav Benes wrote:
> Hi,
>
> On Tue, 9 Sep 2025, 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.
>>
>> Like x86, arch_stack_walk_reliable() should return 0 for user tasks.
>> It is necessary to set regs->csr_prmd as task->thread.csr_prmd first,
>> then use user_mode() to check whether the task is in userspace.
>
> it is a nice optimization for sure, but "unreliable stack" messages point
> to a fact that the unwinding of these tasks is probably suboptimal and
> could be improved, no?
Yes, makes sense, I will fix "unreliable stack" in the next version.
> It would also be nice to include these messages (not for all tasks) to the
> commit message.
OK, will do it.
Thanks,
Tiezhu
Powered by blists - more mailing lists