[Solved] Symbol issue within kernel module #214
Labels
Comments
|
CoreFreq was not designed with perf compatibility. It is explained in project Wiki However with Intel processors I have been able to make them run simultaneously, if no PMC counters programming conflicts happen. What's your processor ? For security purpose |
|
That's a Ryzen, 3900X But that's what I've been looking into, perf top crashes, and it seems it crashed because of the previous message, from a strace. perf tries to read kallsyms, and gets killed because of the page fault |
|
Arch Linux: after a full system rolling upgrade with a EDIT: now rebooting for CoreFreq...
|
|
This could happen in those two |
|
Can I provide anything ? |
It looks like CoreFreq driver has some much symbols that I have searched into the kernel documentation for such limitations. Nothing found. Although I'm aware that with time To track the issue I don't see another immediate solution than tracing the kernel on these parts:
Could you help with this or another debug way ? |
|
Yeah sure. Can you give me a patch or just an example printk so I do exactly what you want ? |
int module_get_kallsym(unsigned int symnum, unsigned long *value, char *type,
char *name, char *module_name, int *exported)
{
struct module *mod;
preempt_disable();
list_for_each_entry_rcu(mod, &modules, list) {
struct mod_kallsyms *kallsyms;
if (mod->state == MODULE_STATE_UNFORMED)
continue;
kallsyms = rcu_dereference_sched(mod->kallsyms);
if (symnum < kallsyms->num_symtab) {
const Elf_Sym *sym = &kallsyms->symtab[symnum];
size_t len = 0;
*value = kallsyms_symbol_value(sym);
*type = kallsyms->typetab[symnum];
len = strlcpy(name, kallsyms_symbol_name(kallsyms, symnum), KSYM_NAME_LEN);
if (len == 0) {
printk("strlcpy(name[%s])>%ld\n",name,len);
}
len = strlcpy(module_name, mod->name, MODULE_NAME_LEN);
if (len == 0) {
printk("strlcpy(module_name[%s], mod->name[%s])>%ld\n",
module_name, mod->name, len);
}
*exported = is_exported(name, *value, mod);
preempt_enable();
return 0;
}
symnum -= kallsyms->num_symtab;
}
preempt_enable();
return -ERANGE;
}EDIT: (re)building the kernel in progress, I will tell you the results ... |
|
|
OK, now changing to print all names going through this function ... int module_get_kallsym(unsigned int symnum, unsigned long *value, char *type,
char *name, char *module_name, int *exported)
{
struct module *mod;
preempt_disable();
list_for_each_entry_rcu(mod, &modules, list) {
struct mod_kallsyms *kallsyms;
if (mod->state == MODULE_STATE_UNFORMED)
continue;
kallsyms = rcu_dereference_sched(mod->kallsyms);
if (symnum < kallsyms->num_symtab) {
const Elf_Sym *sym = &kallsyms->symtab[symnum];
size_t len = 0;
*value = kallsyms_symbol_value(sym);
*type = kallsyms->typetab[symnum];
len = strlcpy(name, kallsyms_symbol_name(kallsyms, symnum), KSYM_NAME_LEN);
printk("strlcpy(name[%s])>%ld\n",name,len);
len = strlcpy(module_name, mod->name, MODULE_NAME_LEN);
if (len == 0) {
printk("strlcpy(module_name[%s], mod->name[%s])>%ld\n",
module_name, mod->name, len);
}
*exported = is_exported(name, *value, mod);
preempt_enable();
return 0;
}
symnum -= kallsyms->num_symtab;
}
preempt_enable();
return -ERANGE;
} |
whereas |
|
I don't find a solution. |
|
A fix is available in the |
|
Hi, Problem fixed for me Thanks a lot |
You are welcome. |
|
When
|
This is indeed linked with |
cyring
added a commit
that referenced
this issue
Jan 23, 2022
|
EDIT:
|
cyring
changed the title
cyring
changed the title
|
What! |
|
Mainline Kernel does not want but latest xanmod of 5.15.36 is doing fine with kallsyms plus CoreFreq Unsolved. Issue is postponed. |
Solution
make CC='cc -fno-inline' clean allln -s src/CoreFreq/corefreqk.ko /lib/modules/$(uname -r)/kernel/drivers/misc/
depmod -a
Perf profiling use-caseinsmod corefreqk.ko Register_ClockSource=1 Register_Governor=1 Register_CPU_Freq=1 Register_CPU_Idle=1 NMI_Disable=0
./corefreqdcorefreq-cli -t interrupts
|
cyring
changed the title
|
Root cause was address relocation. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
perf tries to read /proc/kallsyms. And this occurs when the corefreq module is loaded:
an extract from dmesg:
Do I need to provide something else ?
The text was updated successfully, but these errors were encountered: