Linux创始人林纳斯·托瓦兹（Linus Torvalds）正在进一步探索人工智能编程工具在内核开发中的应用。继日前借助Anthropic的Claude Code开发Linux内核性能优化补丁后，托瓦兹又利用大型语言模型（LLM）分析一段长期以来难以理解的内核代码，不仅确认了开发者此前报告的一个缺陷，还发现了另外三个潜伏十余年的漏洞。这些问题均与Linux内核中的关联数组（Associative Array）实现有关。
根据Phoronix于10月12日发布的报道，托瓦兹近日在自己的Linux内核代码仓库中新增了一个名为“assoc-array-fixes”的Git标签，用于整理和标记针对关联数组代码的一系列修复工作。这项工作与他此前使用Claude Code优化文件读取性能的项目相互独立，但都体现出他正在尝试将AI工具引入复杂的内核开发流程。
此次工作的起因，是开发者尼尔斯·奥尔罗格（Nils Ollrogge）报告了关联数组库中的一个错误，并提交了相应的修复补丁。然而，托瓦兹在审查补丁时发现，相关代码的实现方式过于晦涩，难以直接理解其具体逻辑，因此无法轻易判断补丁是否正确解决了问题。
面对这一情况，托瓦兹选择借助现代大型语言模型辅助分析。他在Git标签说明中写道，自己这次采取了此前一直倡导的做法，即利用现代LLM工具帮助理解复杂代码。
托瓦兹随后组织了一组经过AI辅助修改的补丁，将部分规模庞大、难以阅读的函数拆分成更清晰的结构，使代码逻辑更容易理解和审查。值得注意的是，这项工作的目标并不是简单地让AI重新编写整个关联数组实现，而是先改善现有代码的可读性，再通过测试验证其行为是否符合预期。
完成修改后，相关代码还被放入用户空间的测试框架中运行。测试不仅确认了奥尔罗格最初报告的错误确实存在，还进一步发现了另外三个问题。
更令人关注的是，这些缺陷并非最近引入的新问题。根据托瓦兹的说明，三个额外发现的漏洞可以追溯到2013年首次将该关联数组库引入Linux内核时。换言之，它们已经潜伏在代码中超过十年，期间一直没有被相关测试充分发现。
Linux内核中的关联数组是一种用于按照键值组织和检索数据的数据结构。与普通数组通过整数下标访问元素不同，关联数组能够根据特定的键查找对应的数据，因此适用于需要灵活索引和管理对象的场景。
Linux内核中的关联数组实现服务于内核内部的数据管理需求。由于内核代码必须在严格的性能、内存安全和并发访问要求下运行，这类基础组件的实现通常比普通应用程序中的同类代码更加复杂。即使某个函数表面上只是执行数据插入、删除或查找，也可能涉及树状结构调整、节点生命周期管理以及各种边界条件。
这类代码一旦缺乏清晰的结构，就会增加维护者理解其行为的难度。开发者不仅需要确认正常情况下的运行逻辑，还必须分析异常输入、特殊数据结构状态以及连续执行多个操作时可能出现的问题。
随着代码不断演进，早期实现中不容易触发的缺陷也可能长期留存。尤其是在复杂的数据结构中，某些错误只有在特定操作顺序或特殊结构状态下才会暴露，普通测试不一定能够覆盖所有情况。
此次AI辅助工作采用的思路，是先将难以理解的大型函数拆分为更容易分析的部分，再通过独立测试程序验证相关逻辑。更清晰的代码结构有助于开发者识别不同操作之间的关系，也使测试工具更容易针对具体行为构建验证条件。
不过，不能简单地将这次发现的三个漏洞归因于AI本身具有超越人类的程序理解能力。更准确地说，AI辅助代码重构、开发者审查以及测试框架共同发挥了作用。大型语言模型能够帮助整理代码逻辑、提出潜在问题，但最终仍需要通过实际执行和可重复的测试确认缺陷是否真实存在。
这一案例的特殊之处在于，AI不仅参与了代码分析，还帮助托瓦兹解决了补丁审查过程中的理解障碍。对于维护大型开源项目的开发者而言，这可能是一种具有现实价值的工作方式：当代码过于复杂，导致维护者难以迅速判断修复方案是否正确时，可以先利用AI辅助梳理代码结构，再通过测试和人工审查验证结论。
目前，这组针对关联数组的修复补丁尚未合并到Linux内核主线。按照Phoronix的报道，相关工作预计可能在即将到来的Linux 7.4合并窗口期间进一步推进，但最终是否合并，仍取决于后续代码审查和测试结果。
值得注意的是，这已经不是托瓦兹近期第一次公开展示AI在Linux内核开发中的用途。
此前，他借助Claude Code开展了另一项内核优化工作，目标是解决多个线程同时读取同一个文件时，内存页引用计数操作引发的竞争问题。相关补丁通过调整文件读取路径，尝试减少不必要的引用计数操作，从而改善特定工作负载下的读取性能。
在那项工作中，AI参与了初始代码编写、测试程序开发、代码审查以及补丁说明文档的起草。托瓦兹则负责确定优化方向、监督开发过程，并在自己的计算机上开展性能测量。
两项工作的技术目标并不相同，但体现了类似的开发模式：由熟悉内核的工程师确定问题，再借助AI协助理解复杂实现、编写或调整代码，最后通过测试验证结果。
对于Linux这样规模庞大、维护周期漫长的开源项目而言，这种模式可能尤其有价值。内核代码经过数十年的持续演进，包含大量历史实现和复杂的兼容性要求。即使是经验丰富的维护者，也不可能始终熟悉每个子系统的全部细节。
传统代码审查主要依赖开发者阅读代码、分析逻辑并设计测试。AI工具则有机会帮助维护者更快地梳理陌生代码、解释函数之间的关系、提出可能的边界条件，并辅助生成测试用例。它们并不能取代专业审查，但有望降低理解复杂代码的时间成本。
与此同时，AI生成代码也存在局限。大型语言模型可能误解复杂的控制流程，忽略罕见的边界条件，或者提出表面合理、实际上无法保证正确性的修改。对于操作系统内核而言，这些问题尤其重要，因为代码错误可能影响系统稳定性、内存安全乃至整个系统的可靠运行。
因此，AI参与内核开发并不意味着可以放松审查要求。相反，代码重构、自动化测试、补丁审查和实际验证仍然是确保修改质量的关键环节。此次关联数组项目能够发现长期存在的问题，恰恰说明AI工具需要与严格的工程验证流程结合，才能发挥实际作用。
托瓦兹此前对AI编程工具的态度一直比较务实。他认可AI在开发过程中提供帮助的价值，但并没有主张开发者可以不经审查地接受机器生成的代码。此次他公开说明自己使用LLM分析代码，也进一步表明，AI正在成为内核开发工具箱中的一种辅助选择。
从更广泛的角度看，这一事件还揭示了维护大型软件项目的一项长期难题：代码不仅需要能够正确运行，还必须让未来的开发者能够理解它。对于持续维护十余年甚至数十年的基础软件而言，可读性本身就是影响可靠性的重要因素。
此次修改通过拆分复杂函数来改善代码结构，并借助测试发现此前遗漏的问题，说明代码可读性与缺陷排查之间存在密切联系。当程序逻辑更清晰时，开发者就更容易识别潜在的错误路径，也更容易构建覆盖相关行为的测试。
如果这组补丁最终进入Linux主线，它带来的意义将不仅是修复四个已识别的问题，还包括为后续维护提供更加清晰的代码基础。
随着AI编程工具不断发展，未来大型开源项目可能会出现更多类似案例。不过，对于Linux内核这样的关键基础软件而言，真正决定AI辅助开发能否获得长期认可的，仍然是补丁能否通过严格审查、测试能否复现问题，以及最终代码是否足够可靠。
这一次，AI并没有取代Linux创始人作出最终判断，而是帮助他理解原本难以审查的代码，并进一步挖掘出隐藏多年的缺陷。对于成熟软件工程而言，这或许正是人工智能最具现实价值的应用方向之一。
本文由 AI图鉴自动抓取并翻译，版权归原作者所有；如需查看原文请点下方链接。
Linux founder Linus Torvalds is further exploring the application of artificial intelligence programming tools in nuclear development. Following the recent development of the Linux kernel performance optimization patch using Claude Code in Anthropic, Tovac used the Large Language Model (LLLM) to analyse a long-ununderstood kernel code, not only identifying a flaw previously reported by the developers, but also identifying three other loopholes that have been in hiding for more than a decade. These questions are all related to the achievement of associated arrays in the Linux inner core.
According to Phoronix, on 12 October, publish, Tawaz recently added a Git label called “assoc-array-fixes” to his Linux nuclear code warehouse for a series of restorations of associated array codes. This work is independent of his previous project to optimize document reading performance using Claude Code, but reflects his attempts to introduce AI tools into complex kernel development processes.
The work was prompted by the fact that the developer, Nils Ollrogge, reported an error in the associated array library and submitted the corresponding restoration patches. However, in examining the patches, Tovac found that the code was being achieved in a way that was too obscure to understand its specific logic and that it was therefore not easy to judge whether the patches had solved the problem correctly.
In response to this situation, Tovac chose to use modern large language models to aid analysis. In his Git label note, he wrote that he had taken the approach he had been advocating this time, using modern LLM tools to help understand complex codes.
Tovarz then organized an AI-assisted set of patches that brought into clearer structure the large, hard-to-read function split, making code logic easier to understand and review. It is worth noting that the goal of this exercise is not simply to allow AI to re-write the entire associated array, but to improve the readability of existing codes before testing to verify whether its behaviour is in line with expectations.
When the change is completed, the code is also placed in the test frame of the user space. The test not only confirmed the existence of the errors originally reported by Orrog, but also identified three further problems.
Of even greater concern is that these deficiencies are not new issues recently introduced. According to Tovac, three additional gaps can be traced back to the first time that the associated array was introduced into the Linux kernel in 2013. In other words, they have been hidden in codes for more than 10 years and have not been fully detected during this period.
Linked arrays in the Linux kernel are a data structure used to organize and retrieve data by key. Unlike normal arrays, which access elements through integer subscripts, associated arrays are able to search for the corresponding data according to a specific key and therefore apply to scenes that require flexible indexing and management of objects.
Linked arrays in the Linux kernel meet the data management needs for service within the kernel. Since kernel codes must operate under strict performance, memory security and simultaneous access requirements, the realization of such basic components is often more complex than the equivalent codes in common applications. Even if a function appears to perform data insertion, deletion or search, it may involve tree-shaped restructuring, nodal life cycle management and boundary conditions.
The lack of a clear structure for such codes makes it more difficult for defenders to understand their behaviour. Developers need not only to confirm normal operation logic, but also to analyse abnormal input, special data structure state and problems that may arise when multiple operations are performed continuously.
As the code evolves, the defects that are not easily triggered in early realization may also be retained for long periods. In particular, in complex data structures, certain errors are exposed only in a given order of operation or in a special structural state, and ordinary tests do not necessarily cover all situations.
The idea behind the AI support exercise was to first make the comprehensible large function split an easier part of the analysis and then validate the logic through an independent testing process. A clearer code structure helps developers to identify relationships between different operations, and makes testing tools easier to construct performance-specific verification conditions.
However, it cannot simply be attributed to AI ' s own ability to understand processes beyond humanity. More precisely, AI-AIS re-construction, developer review and testing framework work together. Large language models can help organize code logic and raise potential questions, but ultimately there is a need to confirm whether deficiencies are real or not through actual implementation and repetitious testing.
The particular feature of this case is that AI was not only involved in code analysis, but also helped Tovac to address the barriers to understanding in the patch review process. For developers of large open source projects, this may be a realistic way of working: When the code is too complex to enable the maintainer to quickly judge the correctness of the repair programme, the conclusions can be validated through testing and manual review using the AI-assisted combo code structure.
Currently, this set of patches for associated arrays has not been merged into the Linux nuclear main line. According to Phoronix, work may be expected to advance further during the forthcoming Linux 7.4 consolidation window, but eventual consolidation will depend on subsequent code review and test results.
It is noteworthy that this is not the first time that Tovac has publicly demonstrated the use of AI in the Linux nuclear development in recent times.
He had previously undertaken another kernel optimization exercise through Claude Code, with the aim of resolving competition problems arising from the memory page reference counting operation when multiple threads read the same document simultaneously. The relevant patch improves the reading performance of a given task load by adjusting the file reading path and trying to reduce unnecessary reference count operations.
In that work, AI was involved in the preparation of the initial code, the development of the test program, the code review and the drafting of the patch note document. Tovac is responsible for determining the direction of optimization, supervising the development process and performing performance measurements on its own computer.
The technical objectives of the two jobs are not the same, but they represent a similar development model: Problems are identified by engineers familiar with kernels, assisted by AI in understanding complex realization, preparation or adjustment of codes, and finally tested through testing.
This model may be particularly valuable for open-source projects as large as Linux and with a long maintenance cycle. The kernel code has evolved over the decades and contains numerous historical requirements for compatibility and complexity. Even experienced maintainers cannot always be familiar with the full details of each subsystem.
Traditional code reviews rely mainly on developers to read codes, analyse logic and design tests. The AI tool has the opportunity to help maintainers more quickly combo the unknown code, explain the relationship between functions, propose possible boundary conditions and assist in generating test examples. They do not replace professional reviews, but they are expected to reduce the time cost of understanding complex codes.
At the same time, there are limitations to the AI generation code. Large language models may misinterpret complex control processes, ignore rare border conditions, or propose changes that appear reasonable and do not actually guarantee correctness. These issues are particularly important in the case of nuclear systems in the operating system, as code errors may affect system stability, memory security and even reliable operation of the system as a whole.
Thus, AI ' s involvement in kernel development does not mean that censorship requirements can be relaxed. On the contrary, code re-engineering, automated testing, patch review and physical validation remain key elements in ensuring the quality of modifications. This associated array project has been able to identify long-standing problems, suggesting precisely that the AI tool needs to be combined with a rigorous engineering validation process to be effective.
The approach of Tovac to the AI programming tool has been more pragmatic. He recognized the value of AI ' s assistance in the development process, but did not argue that developers could accept machine-generated codes without censorship. This time, he publicly stated that he was using the LLM analysis code and further indicated that AI was becoming a supporting option in the kernel development toolbox.
More broadly, the event also revealed a long-standing challenge in maintaining large-scale software projects: codes needed not only to function correctly, but also to be understood by future developers. Readability itself is an important factor influencing reliability for the continued maintenance of basic software for more than a decade or decades.
This modification improved the code structure through the split complex function and, by means of tests, identified previously omitted problems, explaining the close link between code readability and gap screening. When the logic of the program is clearer, it is easier for the developers to identify potential error paths and to construct tests that cover the behavior.
If this set of patches eventually enters the Linux main line, it will have implications not only for repairing the four identified problems but also for providing a clearer code base for subsequent maintenance.
As the AI programming tool evolves, more similar cases may arise in future large open source projects. However, for key basic software such as the Linux kernel, the real determination of whether AI-aided development can be long-term recognized remains the question of whether patches can be thoroughly reviewed, re-emerged through testing, and whether the final code is reliable enough.
This time, AI did not replace the Linux founder in his final judgement, but helped him to understand the code that would otherwise be difficult to review and to further exploit the flaws that had been hidden for many years. This is perhaps one of the most realistic applications of artificial intelligence for mature software engineering.
Auto-fetched and translated by AI Atlas. All rights belong to the original author.