select 能否被内核模块不间断地阻塞？

Question

tl;dr:即使指定了超时，对读取文件描述符(指向 procfs 内核模块)的 select 调用是否会最终无限期阻塞？

我在嵌入式 Linux 系统中工作，我们有几个管理服务访问的内核模块。一个这样的模块监控 VLAN 的状态变化。它将接口(interface)导出到 /proc 下的目录中。进程可以通过尝试从那里创建的 proc_file 中读取来将通知绑定(bind)到此模块。当发生变化时，模块将在该接口(interface)上提供数据，调用者的读取将返回信息。

这似乎是导致问题的原因，因为内核模块使用内核信号量(结构信号量)阻止了调用者的读取。我认为这会导致调用者进入“D”或不可中断的阻塞状态。该进程无法正确终止，如果终止则仍然不存在。它不仅不存在，而且没有释放其资源。

我认为这是“不要那样做”的情况，但我不是内核模块方面的专家。似乎更好的方法是在模块中使用自旋锁或 wait_event_interruptable。更改这些遗留内核模块是一件大事，因此我尝试通过在读取之前使用 select 检查 FD 来解决这个问题。但是，这似乎也会无限期地阻止。

有没有办法在不改变内核模块中使用的互斥锁的情况下纠正这个问题？

Answer 1

Linux 允许内核模块执行各种破坏正确程序的恶意操作。恐怕没有比“不要加载错误或恶意模块”更好的答案了。在您的情况下，由于您需要它们，您可能只需要修复它们。