[BUG REPORT] Potential deadlock on epoll Mutex

[CatlessFish]

LockedEventPoll互斥锁在 SIGPROF timer hardirq 下可能发生同锁重入死锁

问题摘要

当前在kernel/src/filesystem/epoll/event_poll.rs中有多处epoll.0.lock()获取epoll文件锁的场景，例如在epoll_wait_with_file内：

DragonOS/kernel/src/filesystem/epoll/event_poll.rs

Line 356 in 7376eae

let epoll_guard = epoll.0.lock();

当线程正在执行epoll相关操作并持有这把锁时，如果本 CPU 的 timer hardirq 恰好到来，且 ITIMER_PROF 到期触发 SIGPROF，内核会在 hardirq 主链路中沿着以下调用链执行：

• tick_handle_periodic
• update_process_times
• irqtime_account_process_tick
• send_signal_to_pcb(SIGPROF)
• complete_signal
• notify_signalfd_for_pcb
• notify_signal
• wakeup_epoll

而wakeup_epoll中可能会再次获取同一个epoll对象的锁，从而形成“进程上下文持普通自旋锁，被本 CPU hardirq 重入同锁”的自锁死。

DragonOS/kernel/src/filesystem/epoll/event_poll.rs

Line 840 in 7376eae

let mut epoll_guard = epoll.lock();

影响范围

理论上，线程只要满足以下条件：

• signalfd 的 mask 包含 SIGPROF
• 线程创建 epoll 并将 signalfd fd 加入该epoll
• 线程启用了 ITIMER_PROF

那么线程就可能在执行 epoll 相关代码的持锁窗口内进入中断，随后发生死锁。