实现CPU频率调节器内核模块时调用printk()触发Kernel Oops求助

Hey there, let's break down the common reasons you might be hitting a Kernel Oops when using printk() in your custom cpufreq governor module, especially since you're building off the performance governor template:

1. Malformed Printk String #

Looking at your code snippet, the printk line has an invalid newline character:

printk(KERN_INFO "DEBUG: Frequency set to 1500 MHz.
");

Notice the line break inside the string without a backslash? This creates an unterminated string literal in C, which leads to undefined behavior—including memory corruption that triggers a Kernel Oops.

Fix it by using the proper escaped newline \n:

printk(KERN_INFO "DEBUG: Frequency set to 1500 MHz.\n");

2. Invalid struct cpufreq_policy Pointer #

The cpufreq_gov_performance_limits function receives a policy pointer from the cpufreq subsystem. If this pointer is NULL or points to uninitialized memory when your function is called, even a seemingly harmless printk (or subsequent code) can trigger an Oops.

Add a safety check at the start of your function to validate the pointer:

static void cpufreq_gov_performance_limits(struct cpufreq_policy *policy) {
    if (!policy) {
        printk(KERN_WARNING "cpufreq_gov_performance_limits: Received NULL policy pointer!\n");
        return;
    }
    printk(KERN_INFO "DEBUG: Frequency set to 1500 MHz.\n");
    // Rest of your code...
}

3. Unfinished/Invalid Code After printk() #

Your code cuts off at __cpufreq_driver_ta...—if this is a call to a function like __cpufreq_driver_target() with incorrect parameters (e.g., a NULL pointer, invalid frequency value), the Oops might be originating there but you're associating it with the preceding printk.

Debug this by checking the full Oops trace in dmesg. Look for the instruction pointer address and use addr2line with your module's debug symbols to pinpoint the exact line:

addr2line -e your_custom_governor.ko <faulting_instruction_address>

Make sure you built your module with debug info enabled (add -g to your Makefile's CFLAGS).

4. Execution Context Conflicts #

While printk is safe to use in both process and interrupt contexts, if your governor callback is running in an interrupt context and your code (even accidentally) tries to perform a blocking operation later, that could trigger an Oops. To rule this out, add a context check:

printk(KERN_INFO "DEBUG: Running in interrupt context? %d\n", in_interrupt());

If the output is 1, ensure you avoid any sleepable operations (like kmalloc with GFP_KERNEL, mutex locks, etc.) in your function.

内容的提问来源于stack exchange，提问作者Chrls Crds