最近，一些内核开发者一直在尝试解决最近在英特尔硬件中发现的大量、可怕的、长期的安全漏洞。在这个过程中，出现了一些关于编码实践的有趣的评论。

Christoph Hellwig 和 Jesper Dangaard Brouer 正在努力缓解为了避开英特尔巨大的安全漏洞而需要做出的一些巨大的速度牺牲。并且，Christoph 说，这样一个补丁可以将网络吞吐量从每秒 750 万个数据包提高到 950 万个——速度提升 25%。

为了做到这一点，该补丁将检查内核的“快速路径”中是否有任何 dma_direct_ops 的实例，并将它们替换为简单的直接调用。

Linus Torvalds 喜欢这段代码，但他注意到 Jesper 和 Christoph 的代码有时会在测试快速路径之前执行某些测试。但是，如果内核实际上正在采用快速路径，则这些测试将是不需要的。Linus 说：“你让快速情况变得不必要地慢了。”

他建议切换测试的顺序可以立即解决问题。他补充说

实际上，作为进一步的微优化，最好指定 dma_is_direct() ops 是一个特殊指针（甚至可以直接说“NULL 表示它是直接的”），因为这样可以使快速情况测试简单得多（避免了整个讨厌的常量加载，并且特别是测试 NULL 通常要好得多）。

但是，进一步的微优化绝对 *要求* ops 指针测试首先进行。因此，进行这种排序更改不仅是“为避免额外的缓存访问而为快速情况生成更好的代码”，而且还允许未来的优化。

关于 Linus 的微优化，Christoph 解释说

我想处理 NULL 情况，这会更好。但是 arm 的人们竭尽全力确保他们没有默认的 dma ops 集，并要求在每个设备上显式设置它，以捕获人们没有正确设置的情况，我不想惹恼他们......但是也许我应该直接去做，看看谁会尖叫，因为好处是很明显的。

Linus 还建议，对于 Christoph 和 Jesper 的测试，dma_is_direct() 函数应该确保使用 likely() 调用。这很有趣，因为 likely() 用于提醒编译器，为了优化代码，一段代码比另一段代码“更可能”运行。而且，Christoph 不确定这是真的。他说：“是的，对于常见情况，这很可能。但是，如果您运行一个设置，您总是有一个 iommu，事实并非如此，在这种情况下它永远不会被调用，但我们只在运行时才知道这一点。”

因此，Christoph 担心误导编译器并生成更糟糕的代码。但是 Linus 解释说

请注意，“likely()”没有任何真正巨大的开销——它只是让编译器将不太可能的情况移出内联。

与间接分支的开销相比，这根本不算什么大问题，更多的是误预测和缓存布局问题。

因此，当某些东西不是 “likely()” 时标记它实际上不会过多地惩罚事情。它不像异常或任何类似的东西，它实际上只是一个用于更好代码布局的标记。

就这样。在绝望的悲伤时刻提供的有益提示。这些英特尔硬件安全漏洞简直令人难以置信。我们不断听到新的漏洞被发现，或者新的漏洞利用需要与已有的解决方法不同的方法。

我确信英特尔正在疯狂地工作，以在未来几代硬件中解决所有这些问题。但是关于安全漏洞的事情是，根据定义，它们很难被发现。硬件制造商可以随意检查和探测他们的产品，但仍然会错过世界上一个孤独的行动者有一天偶然发现的东西。这次是英特尔；下次，它将是其他东西。 赞扬英特尔与操作系统人员合作，尽管面临公开的尴尬，也要为这些问题找到好的解决方法。

注意：如果您在上面被提及，并想在评论区上方发布回复，请将您的回复文本发送至 ljeditor@linuxjournal.com。