tl; dr：即使指定了超时，对读取文件描述符（指向 procfs 内核模块）的选择调用是否会无限期地阻塞？
我在一个嵌入式 Linux 系统中工作，我们有几个内核模块来管理对服务的访问。一个这样的模块监视 VLAN 状态的变化。它将接口导出到/proc. 进程可以通过尝试从那里创建的 proc_file 读取来绑定到该模块的通知。当发生变化时，模块将在该接口上提供数据，调用者的读取将返回该信息。
这似乎引起了问题，因为内核模块使用内核信号量（结构信号量）阻止了调用者的读取。我认为这导致调用者进入“D”或不可中断的阻塞状态。该进程无法正确终止，如果终止，该进程仍将失效。它不仅已失效，而且没有释放其资源。
我认为这是“不要那样做”的情况，但我不是内核模块方面的专家。似乎更好的方法是在模块中使用自旋锁或 wait_event_interruptable。更改这些遗留内核模块是一件大事，因此我尝试通过在读取之前使用 select 检查 FD 来解决它。但是，这似乎也无限期地阻塞。
有没有办法在不改变内核模块中使用的互斥锁的情况下纠正这个问题？