如何检测发送到 Linux 内核中特定 scsi 设备的所有 scsi 请求？

如何解决如何检测发送到 Linux 内核中特定 scsi 设备的所有 scsi 请求？

我想创建一个 linux 内核模块，它可以“挂钩”所有发送到某个特定 scsi 设备的 scsi 请求，并对与特定 scsi 请求关联的数据进行密码/解密；更准确地说，现在我想对数据进行异或运算。

所以，我已经尝试做的是：

1. 我注册了一个检测系统中出现新 scsi 设备的通知程序；为此，我调用函数 bus_register_notifier(&scsi_bus_type,...);
2. 我检测到新的 scsi 设备；获取与特定设备关联的 scsi_host 结构并将其 hostt->queuecommand 字段替换为我自己的函数指针；
3. 然后我的钩子函数被调用；在那里，我修改了与请求关联的数据，并用我自己的函数指针替换了 struct scsi_cmnd 中的 scsi_done 字段，以便解密 READ 请求中的数据。

当然，我在描述中省略了很多细节，如果有必要，我准备提供更多细节。

不管怎样，结果如下。我将我的模块插入系统。我将一些设备加入我的虚拟机，我的模块成功检测到它并执行我上面提到的操作。我在设备上创建了一个新分区；移除设备；例如，使用 WinHex 打开它并查看一切是否正确（数据进行了异或运算）；我再次将设备加入虚拟机，系统成功检测到设备，可以挂载（提醒我的模块还在系统中，解密READ请求）。但是，当我将一些文件复制到设备后，移除设备并重新加入，系统无法使用该设备上的文件系统，系统认为文件系统已损坏，因此我唯一能做的就是格式化再次设备。但有时一切正常；我的意思是我复制文件，提取设备，再次加入并查看我的文件。

我猜除了 hostt->queuecommand 之外还有其他一些入口点，用于将用户模式数据传输到设备；因此，正在使用此入口点将数据写入设备，这就是为什么没有按必须的方式进行异或的原因。这个入口点可能在我以安全模式提取设备后使用（我猜是当缓存数据刷新到设备时）。

也许你能告诉我我哪里出错了？哪个入口点不在我的控制之下？或者，您可以建议一些其他方法来完成主要任务：检测 scsi 请求并对与这些请求关联的数据进行异或。