RISC-V无标准库Rust内核中UART锁死时的panic消息打印处理方案咨询

看起来你碰到了嵌入式内核开发里非常典型的死锁场景——当持有UART自旋锁的代码触发panic时，panic handler试图再次获取同一把锁来输出错误信息，结果直接卡在自旋等待上了。我结合no_std Rust和RISC-V QEMU virt平台的场景，给你几个实用的解决方案：

方案一：给panic场景单独实现无锁UART打印路径 #

既然panic发生后系统即将进入halt状态，我们完全可以绕过自旋锁，直接操作UART寄存器来输出信息，不用再考虑正常流程下的并发安全。

首先实现一个专门的panic_print函数：

use core::fmt;

#[doc(hidden)]
pub fn panic_print(args: fmt::Arguments) {
    // 单核环境下直接操作即可；多核的话先关闭当前核心中断，避免其他核心干扰
    unsafe { riscv::interrupt::disable() };

    // 绕过自旋锁，直接获取UART实例的原始指针
    let uart = unsafe { &mut *UART_INSTANCE.data.get() };
    // 忽略写入错误，毕竟panic后系统马上要停机了
    let _ = uart.write_fmt(args);
}

然后修改panic handler，用这个无锁函数代替原来的println!：

#[panic_handler]
fn _panic(info: &PanicInfo) -> ! {
    panic_print(format_args!("KERNEL PANIC: {}\n", info));
    halt();
}

这个方案的优势是简单直接，完全规避了锁的问题，适合大多数小型内核场景。

方案二：给自旋锁添加panic递归检测逻辑 #

如果你希望保持打印逻辑的统一性，不想写两套打印代码，可以给自旋锁加一层判断：当panic handler尝试获取锁时，如果发现锁是当前上下文持有的，就直接跳过等待，强制访问数据。

首先修改自旋锁结构体，添加持有锁的核心ID（单核环境可以简化为一个panic标记）：

use core::sync::atomic::{AtomicBool, AtomicUsize, Ordering};
use core::cell::UnsafeCell;

pub struct Spinlock<T> {
    locked: AtomicBool,
    owner_core_id: AtomicUsize, // 存储持有锁的核心ID，单核固定为0
    data: UnsafeCell<T>,
}

impl<T> Spinlock<T> {
    pub const fn new(data: T) -> Self {
        Self {
            locked: AtomicBool::new(false),
            owner_core_id: AtomicUsize::new(usize::MAX),
            data: UnsafeCell::new(data),
        }
    }

    // 实现一个获取当前核心ID的函数，单核直接返回0即可
    fn get_core_id() -> usize {
        // 示例：读取RISC-V mhartid寄存器
        unsafe { core::arch::asm!("csrr {}, mhartid", out(reg) id => id) }
    }

    pub fn lock(&self) -> SpinlockGuard<'_, T> {
        let core_id = Self::get_core_id();
        loop {
            match self.locked.compare_exchange(false, true, Ordering::Acquire, Ordering::Relaxed) {
                Ok(_) => {
                    self.owner_core_id.store(core_id, Ordering::Release);
                    return SpinlockGuard { lock: self };
                }
                Err(_) => {
                    // 如果当前核心就是锁的持有者，且处于panic状态，直接跳过等待
                    if self.owner_core_id.load(Ordering::Relaxed) == core_id && in_panic() {
                        return SpinlockGuard { lock: self };
                    }
                    core::hint::spin_loop();
                }
            }
        }
    }

    fn unlock(&self) {
        self.owner_core_id.store(usize::MAX, Ordering::Release);
        self.locked.store(false, Ordering::Release);
    }
}

// 全局标记：是否处于panic状态
static IN_PANIC: AtomicBool = AtomicBool::new(false);

fn in_panic() -> bool {
    IN_PANIC.load(Ordering::Relaxed)
}

最后修改panic handler，设置panic标记：

#[panic_handler]
fn _panic(info: &PanicInfo) -> ! {
    IN_PANIC.store(true, Ordering::Relaxed);
    println!("KERNEL PANIC: {}", info);
    halt();
}

这个方案能保持打印逻辑的一致性，但需要处理核心ID和panic状态的检测，适合复杂一点的多核内核场景。

方案三：让println!宏自动适配两种场景 #

我们可以给println!宏加一层判断，自动根据是否处于panic状态选择带锁或无锁的打印路径，这样不管是正常代码还是panic handler里调用println!，都不会出问题。

修改宏定义：

#[macro_export]
macro_rules! println {
    () => ($crate::print!("\n"));
    ($($arg:tt)*) => {
        if $crate::in_panic() {
            $crate::panic_print(format_args!("{}\n", format_args!($($arg)*)));
        } else {
            $crate::print!("{}\n", format_args!($($arg)*));
        }
    };
}

这个方案结合了前两个方案的优点，既不用修改现有代码的打印调用，又避免了死锁问题。

额外注意事项 #

1. UART寄存器的volatile属性：直接操作UART寄存器时，一定要确保用volatile访问（比如用core::ptr::write_volatile/read_volatile，或者封装成VolatileCell），否则编译器可能会优化掉你的写入操作。
2. 避免双重panic：在panic专用的打印函数里，不要再次调用panic!，比如原来_print里的错误处理，在panic场景下直接忽略即可，否则会触发双重panic导致更严重的问题。
3. 多核场景的中断控制：如果是多核内核，panic时最好关闭所有核心的中断，或者只允许当前核心操作UART，避免其他核心在panic过程中干扰UART输出。

内容来源于stack exchange