中断处理程序中调用ioread32引发内核恐慌问题求助

你的内核panic主要由几个明显的错误导致，按优先级排序：

1. IRQ处理程序函数签名完全错误 #

内核规定IRQ处理程序必须遵循固定的函数签名：

irqreturn_t (*irq_handler_t)(int irq, void *dev_id);

你的sample_irq_handler没有定义这两个参数，内核调用该函数时会将参数压入栈中，但你的函数不处理这些参数，直接导致栈帧混乱，触发致命异常——这几乎是你遇到panic的直接原因。

修复后的函数签名：

irqreturn_t sample_irq_handler(int irq, void *dev_id) {
    irqreturn_t ret;
    spin_lock(&lock);
    ret = do_sample_irq();
    spin_unlock(&lock);
    return ret;
}

2. Printk调用语法错误 #

你对printk的用法完全错误，正确的写法是将日志级别作为格式字符串的前缀，而非独立参数：
错误写法：

printk(KERN_INFO, "%x.\n", val);

正确写法：

printk(KERN_INFO "%x.\n", val);

这种参数传递错误会导致内核解析格式字符串时出现混乱，在中断上下文这种敏感环境下直接触发崩溃。

3. 共享IRQ未做设备中断检查 #

对于共享IRQ线，处理程序必须先判断当前中断是否由你的设备触发，不能直接返回IRQ_HANDLED。所有共享该IRQ的设备都会依次执行处理程序：

• 如果确认是自己设备触发的中断，处理后返回IRQ_HANDLED
• 否则必须返回IRQ_NONE，交给其他设备处理

你当前的逻辑不管中断来源直接标记为已处理，会干扰其他共享设备，甚至导致系统无法正确响应中断。

典型的修复逻辑（需根据你的硬件手册调整）：

irqreturn_t do_sample_irq() {
    int val;
    // 读取设备中断状态寄存器，判断是否为本设备触发的中断
    // 示例：假设偏移4字节的寄存器第0位是中断标志位
    if (!(ioread32(mem + 4) & 0x1)) {
        return IRQ_NONE;
    }
    // 读取数据
    val = ioread32(mem);
    printk(KERN_INFO "%x.\n", val);
    // 清除设备中断标志（必须按硬件要求操作）
    iowrite32(0x1, mem + 4);
    return IRQ_HANDLED;
}

4. Ioremap返回值未做有效性检查 #

你调用ioremap_nocache后没有检查返回值是否为NULL。如果传入的addr是无效物理地址，ioremap_nocache会返回NULL，后续调用ioread32(NULL)会触发非法内存访问，直接导致panic。

必须添加检查：

mem = ioremap_nocache(addr, 8);
if (!mem) {
    printk(KERN_ERR "Failed to ioremap device memory\n");
    return -ENOMEM; // 终止模块初始化
}

5. 自旋锁使用冗余 #

IRQ处理程序（顶半部）运行时，本地中断已经处于禁用状态，此时使用spin_lock_irq会再次禁用中断（虽然不会死锁，但属于冗余操作）。正确的做法是使用spin_lock：

spin_lock(&lock);
ret = do_sample_irq();
spin_unlock(&lock);

如果需要更严谨地保存中断状态（比如处理程序可能被其他上下文调用），可以使用spin_lock_irqsave和spin_unlock_irqrestore，但对于纯IRQ顶半部，spin_lock足够。

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