由于 IOCTL 调用，调试内核挂起答案

【问题标题】：Debugging kernel hang because of IOCTL calls由于 IOCTL 调用，调试内核挂起
【发布时间】：2013-02-13 05:14:16
【问题描述】：

我正在尝试使在 2.6.32 内核上运行的内核模块在 3.6 内核上运行。我们使用 IOCTL 调用来更新 Linux 内核模块中的结构。这些调用在 2.6.32 内核中运行良好。

当我在 3.6 内核中尝试相同的操作时，只要从用户空间应用程序进行 ioctl 调用，我就会面临内核挂起。它是基于套接字的接口而不是基于文件的接口，因此我们使用 struct proto_ops 下的 ioctl。

由于没有生成核心转储，我该如何调试这种情况。要从用户空间复制数据，我正在使用 copy_from_user 命令。

任何调试此场景的指针都会非常有帮助

【问题讨论】：

系统挂起后系统日志有什么特别的地方吗？挂起可能是内核 oops 或恐慌等的迹象。即使内核崩溃，您是否尝试过通过串行控制台输出系统日志以可靠地获取它？此外，如果您可以在此处发布代码的相关部分，这可能有助于找出问题所在。

标签： linux module linux-kernel ioctl

【解决方案1】：

ioctl() 是内核的剩余部分之一，在大内核锁 (BKL) 下运行。过去，BKL 的使用使得长时间运行的 ioctl() 方法可以为不相关的进程创建较长的延迟。

以下是对将 unlocked_ioctl 和 compat_ioctl 引入 2.6.11 的补丁的解释。 ioctl 字段的删除发生在很晚的 2.6.36 中。

解释：执行 ioctl 时，它使用了Big Kernel Lock (BKL)，因此不能同时执行其他任何操作。这在多处理器机器上是非常糟糕的，因此需要付出很大的努力来摆脱 BKL。首先，引入了 unlocked_ioctl。它允许每个驱动程序编写者选择使用什么锁。这可能很困难，因此有一段时间旧驱动程序仍然可以工作（使用 ioctl），但新驱动程序可以使用改进的接口（unlocked_ioctl）。最终，所有驱动程序都被转换，并且可以删除 ioctl。

compat_ioctl 实际上是不相关的，即使它是同时添加的。其目的是允许 32 位用户态程序在 64 位内核上进行 ioctl 调用。 ioctl 最后一个参数的含义取决于驱动程序，所以没有办法进行与驱动程序无关的转换。

参考：new way of ioctl()Jonathan Corbet

【讨论】：

所以...那篇文章是 2005 年的，这仍然是真的吗？ file_operations里面有unlocked_ioctl，block_device_operations里面没有unlocked_ioctl。