Hi,
From: Greg KH gregkh@linuxfoundation.org Date: Mon, 6 Feb 2023 10:39:45 +0100
On Mon, Feb 06, 2023 at 05:22:54PM +0800, Xinghui Li wrote:
Greg KH gregkh@linuxfoundation.org 于2023年2月6日周一 13:40写道：
If you rely on the 5.4.y kernel tree, and you need this speculation fixes and feel this is a real problem, please provide some backported patches to resolve the problem.
It's been reported many times in the past, but no one seems to actually want to fix this bad enough to send in a patch :(
Usually people just move to a newer kernel, what is preventing you from doing that right now?
thanks,
greg k-h
Thanks for your reply~ I am sorry about reporting the known Issue. I am trying to fix this issue right now. And I met the CFA issue, so I just want to discuss it with the community.
Is this an actual real problem that you can detect with testing? Or is it just a warning message in the build?
I've just received a related report from a customer and I found the same commit was the first bad one while investigating. I've attached a simple repro below.
After 8afd1c7da2b0 ("x86/speculation: Change FILL_RETURN_BUFFER to work with objtool"), calling stack_trace_save_tsk_reliable() from the kernel module below fails with -EINVAL if CONFIG_UNWINDER_ORC=y and CONFIG_RETPOLINE=y.
I confirmed that this issue does not happen on 5.10 and 5.15 at least (and told the customer to use either).
Interestingly, after the commit, stack_trace_save_tsk_reliable() fails but seems to fill the buffer with the correct stack trace.
---8<--- #include <linux/module.h> #include <linux/kallsyms.h>
typedef int (*func_t)(struct task_struct *tsk, unsigned long *store, unsigned int size);
static __init int buggy_orc_init(void) { unsigned long store[32] = {0}; func_t func; int ret, i;
func = (func_t)kallsyms_lookup_name("stack_trace_save_tsk_reliable"); if (!func) return -ENOENT;
ret = func(current, store, ARRAY_SIZE(store));
for (i = 0; i < ARRAY_SIZE(store); i++) printk(KERN_ERR "%px: %pS\n", (void *)store[i], (void *)store[i]);
return ret > 0 ? 0 : ret; }
module_init(buggy_orc_init);
MODULE_LICENSE("GPL"); ---8<---
---8<--- # insmod buggy_orc.ko [ 8.576683] buggy_orc: loading out-of-tree module taints kernel. [ 8.578414] ffffffff810d1538: stack_trace_save_tsk_reliable+0x78/0xc0 [ 8.578414] ffffffffc000405c: buggy_orc_init+0x5c/0x1000 [buggy_orc] [ 8.579066] ffffffff81000b56: do_one_initcall+0x46/0x1f0 [ 8.579066] ffffffff810f005c: do_init_module+0x4c/0x240 [ 8.579066] ffffffff810f2cbf: __do_sys_finit_module+0xbf/0xe0 [ 8.580379] ffffffff81002198: do_syscall_64+0x48/0x110 [ 8.580379] ffffffff81c00094: entry_SYSCALL_64_after_hwframe+0x5c/0xc1 [ 8.581328] 0000000000000000: 0x0 [ 8.581328] 0000000000000000: 0x0 [ 8.581328] 0000000000000000: 0x0 [ 8.582145] 0000000000000000: 0x0 [ 8.582145] 0000000000000000: 0x0 [ 8.582145] 0000000000000000: 0x0 [ 8.582145] 0000000000000000: 0x0 [ 8.583229] 0000000000000000: 0x0 [ 8.583229] 0000000000000000: 0x0 [ 8.583229] 0000000000000000: 0x0 [ 8.584046] 0000000000000000: 0x0 [ 8.584046] 0000000000000000: 0x0 [ 8.584046] 0000000000000000: 0x0 [ 8.584046] 0000000000000000: 0x0 [ 8.585130] 0000000000000000: 0x0 [ 8.585130] 0000000000000000: 0x0 [ 8.585130] 0000000000000000: 0x0 [ 8.585130] 0000000000000000: 0x0 [ 8.586221] 0000000000000000: 0x0 [ 8.586221] 0000000000000000: 0x0 [ 8.586221] 0000000000000000: 0x0 [ 8.587038] 0000000000000000: 0x0 [ 8.587038] 0000000000000000: 0x0 [ 8.587038] 0000000000000000: 0x0 [ 8.587038] 0000000000000000: 0x0 insmod: ERROR: could not insert module buggy_orc.ko: Invalid parameters ---8<---
Thank you, Kuniyuki
We keep staying in v5.4 because we developed the product base on v5.4 3 years ago. So it is unstable and difficult to update the kernel version.
That is very odd, why is it hard to update to a new kernel? What happens if 5.4 stops being maintained tomorrow, what are your plans to move to a more modern kernel? Being stuck with an old kernel version with no plans to move does not seem like a wise business decision:(
I will try to find out a way to fix this issue.
Great, and we will be glad to review patches.
thanks,
greg k-h