皇上,还记得我吗?我就是1999年那个Linux伊甸园啊-----24小时滚动更新开源资讯,全年无休!

编译器驱动静态分析锁定上下文检查合并至 Linux 7.0

编译器驱动静态分析锁定上下文检查合并至 Linux 7.0

锁定代码更改已合并至 Linux 7.0 内核,并引入了即将在编译器端通过即将到来的 LLVM Clang 22 引入的新编译器驱动功能的支持。

作为 Linux 7.0 锁定更改的一部分合并的新功能是编译器驱动的静态分析锁定上下文检查,可以在使用 LLVM Clang 22+构建内核时使用。此功能在拉取请求中描述为:

“实现编译器驱动的静态分析锁定上下文检查,使用即将推出的 Clang 22 编译器的上下文分析功能。(Marco Elver)

我们移除了 Sparse 上下文分析支持,因为在移除之前,即使是 defconfig 内核也会产生 1,700+ 个上下文跟踪 Sparse 警告,其中绝大多数是误报。在 allmodconfig 内核上,误报的上下文跟踪 Sparse 警告数量增长到超过 5,200… 另一方面,Sparse 上下文分析实际发现的锁定错误也相当稀少:我在过去 3 年中只发现了 3 个这样的提交。因此,误报率和维护开销相当高,目前似乎没有采取任何积极政策来实现零警告基线,将注解和修复器移交给引入新代码的开发者。

Clang 上下文分析在原则上更为完整,且更积极地尝试发现错误。此外,它的启用方式也不同:它是按子系统逐个启用的,这导致在所有相关的内核构建中都没有警告(至少在我们的测试范围内是这样)。这使我们能够默认启用它,类似于其他编译器警告,并预期未来不会再出现警告。这为 clang-22+构建强制执行了零警告基线。(诚然,这些构建在分发上仍然有限。)

希望 Clang 方法能够带来更可维护的零警告状态和策略,随着越来越多的子系统和驱动程序启用该功能。通过设置 WARN_CONTEXT_ANALYSIS_ALL=y(默认禁用),可以为所有内核代码启用上下文跟踪,但这将产生大量误报。”

锁定的补丁还带来了许多 Rust 集成更新和其他修复。所有这些更改都已成功合并到 Linux Git 中,用于大型 Linux 7.0 发布。

转自  Compiler-Driven Static Analysis Locking Context Checking Merged For Linux 7.0 – Phoronix