The Assisted-by tag, used to disclose AI involvement in Linux kernel development, is no longer required. Following discussion at the invitation-only Linux Kernel Maintainer Summit, Sasha Levin submitted a patch removing the requirement on October 9, 2026, and Jonathan Corbet picked it up on October 14. It was then merged, as a Documentation update for Linux 7.4, into the mainline repository managed by Linus Torvalds by October 21. However, the documentation for the officially released Linux 7.3 still contains the old requirement.
The change reflects the fact that AI-use disclosure was not working well in practice. Of the unmerged commits accepted through the seventh release candidate (-rc7) of Linux 7.3, only about 10% carried the Assisted-by tag. Meanwhile, the rule that AI must not add a Developer Certificate of Origin sign-off, and the rule that maintainers may reject patches the submitter cannot understand or explain, remain in place. In a note to The Register columnist Steven J. Vaughan-Nichols, Torvalds also explained that the problem is not the use of AI itself but submitting patches without understanding the code. The change can be seen as a shift away from formal declarations of whether AI was used and toward whether submitters can take responsibility for what they submit.
How AI-disclosure rules changed from Linux 7.0 to 7.4
The first patch Levin submitted on October 9 changed four files, adding one line and removing 51. Its commit message was brief, just two sentences. But the version finally merged into mainline (commit 1e03529) expanded to one line added and 88 removed, and it also covers the Italian, Brazilian Portuguese, and Traditional Chinese translations of the documentation. The commit message gained explanations: only about 10% of the 18,533 unmerged commits through Linux 7.3-rc7 carried the tag, and although the Maintainer Summit was not unanimous, there was strong support for removing the requirement. Greg Kroah-Hartman, who had argued for keeping the tag in the July discussion, reportedly supported removal this time.
Specifically, the section explaining the format and usage examples of the Assisted-by tag was removed entirely from coding-assistants.rst. In submitting-patches.rst, the passage asking for AI use to be indicated with the tag, and warning that omitting it could hinder acceptance of a patch, is gone. In checkpatch.pl, which checks patch formatting, Assisted-by: was also removed from the list of recognized signature tags. In addition, step 6 of the AI bug-fix procedure changed from "do not add Signed-off-by; add an Assisted-by tag" to simply "do not add Signed-off-by." The patch, however, contains no language prohibiting use of the Assisted-by tag itself.
Comparing the revision history of coding-assistants.rst shows that the method of disclosing AI use has been simplified step by step. In Linux 7.0 through 7.2, the format named the AI agent and model version; in 7.3 it was replaced with the generic label "LLM" for large language models. In the documentation for the next version, the attribution section itself has been deleted.
| Linux version / documentation state | Assisted-by format | Bug-fix step 6 | AI Signed-off-by |
|---|---|---|---|
| v7.0, v7.1 | Assisted-by: AGENT_NAME:MODEL_VERSION [TOOL1] [TOOL2] |
No such procedure section | Prohibited |
| v7.2 | Same as above | Do not add Signed-off-by; add an Assisted-by tag | Prohibited |
| v7.3 (current release as of October 18) | Assisted-by: LLM [TOOL1] [TOOL2] |
Same as above | Prohibited |
| For linux-next (as of October 23) | No such section | Do not add Signed-off-by | Prohibited |
| Mainline master (checked October 24) | No such section | Same as above | Prohibited |
What this comparison makes clear is that what changed is the rule on how AI use is recorded, not the rule on the submitter's responsibility. Across every version in the table, the rule that AI must not add Signed-off-by has been consistently maintained. Even without the Assisted-by tag, the mechanism by which a human takes responsibility for a patch's content and provenance is unchanged.
Signed-off-by is a signature line at the end of a patch's commit message indicating that the submitter agrees to the DCO (Developer Certificate of Origin). The DCO is a mechanism for developers to declare for themselves, among other things, that they have the right to submit the code they are contributing. Kernel documentation states that only a human can make this legally meaningful certification. Therefore, even when code is AI-generated, the human submitter must review everything, confirm license compliance, and add their own Signed-off-by.
Unlike such a signature, which shows where responsibility lies, the Assisted-by tag was meant to record the fact that AI was used in development. Even with that requirement removed, the principle that the submitter understands the patch and bears responsibility for it remains. Even if AI generated most of the code, the responsible party is still the human who signed.
Furthermore, the removal patch did not touch another document, generated-content.rst. That document asks that, when a submission contains a substantial amount of tool-generated material produced by someone other than the signer, its origin be made clear through the cover letter and commit message. A cover letter is the email placed at the head of a series of patches that explains the purpose and background of the changes as a whole. Examples of information to disclose include the tools used, a summary of prompts, which parts AI was involved in, and the testing performed.
The same document also states that submitters must fully understand the patch and be able to explain and justify the change. If they cannot, they should not submit it, and maintainers may reject such patches without detailed review. They may also request additional testing or lower the review priority. This provision was already referenced from coding-assistants.rst in Linux 7.3 and is not newly introduced. In other words, even without the Assisted-by tag requirement, transparency about the origin of AI-generated material and responsibility for understanding and explaining one's submission are still required.
The Assisted-by requirement survived in July and was removed in October
This is not the first time the Linux kernel has moved to document how AI may be used. On July 25, 2025, Sasha Levin submitted a patch titled "Add initial set of rules and docs," adding initial rules on AI use. It added 68 lines of rules to Documentation/AI/main.md, including making AI involvement explicit in commits and forbidding AI from adding Signed-off-by. This document, however, is a separate file from the later-added coding-assistants.rst.
Linux 7.0 added coding-assistants.rst, and according to LWN, the language requiring use of the Assisted-by tag was introduced at that time. Then, on July 2, 2026, Jeff Layton submitted a patch removing the LLM attribution requirement. Layton noted that although several months had passed since the requirement was introduced, the signal-to-noise ratio of the information gained was very low. He gave three reasons: the rule was not consistently followed, it amounted to free advertising for proprietary LLM companies, and it was unclear what the information was being collected for.
The key maintainer Greg Kroah-Hartman opposed this proposal. He argued that the name and format recorded in the tag do not matter, but the information that an LLM was used does. Knowing that, one can review the patch accordingly, and if the declaration is false, the responsibility lies with the submitter. He explained that the tags had already proven useful in several patches in the subsystems he handles, and that AI would be used more often going forward. At that stage, the Assisted-by requirement was retained.
On July 14, during a discussion about Sashiko, an AI-based automatic reviewer for kernel patches, Torvalds made his own position on AI use clear. He said "Linux is not an anti-AI project," explaining that AI is, like other development tools, clearly a useful instrument. That statement was not directly about the Assisted-by tag, but it showed that Linux kernel development does not reject AI use itself.
The turning point was the invitation-only Linux Kernel Maintainer Summit held in Prague on October 8. In a one-day gathering of about 30 participants, the discussion centered on LLM use, according to a record by LWN's Jonathan Corbet. The next day, when Levin submitted the patch removing the Assisted-by requirement, Krzysztof Kozlowski pointed out that, although it reversed an earlier consensus, the reasons were not adequately explained. He did not object to changing the requirement itself but held that the grounds for the change of course should be shown.
In July, Kroah-Hartman opposed Layton's removal proposal and the requirement stayed. About three months later, the day after the Maintainer Summit, Levin submitted a patch with the same aim, and this time Kroah-Hartman was among those supporting removal. The patch was accepted on October 14 and merged into mainline by October 21. What supported this change of course was the strong support for abolishing the requirement at the summit and the track record of tag use at only about 10%.
About 10% tagged: why self-reporting didn't work
Of the 18,533 unmerged commits accepted through Linux 7.3-rc7, 1,884 carried the Assisted-by tag, about 10.2% of the total. However, this figure cannot be interpreted as the disclosure rate among AI users or the rate of compliance with the rule. The denominator is all unmerged commits, not commits that used AI, so it is unknown how many changes actually used AI. Corbet believes the real number of patches created with LLMs is far higher than this figure.
Corbet himself also raised the question of the tag's effectiveness at the Maintainer Summit. Many contributors use LLMs without adding the tag; some don't know the rule, and others deliberately try to hide that they used AI. In addition, few maintainers check whether the tag is present, so as a result the tag is not useful as a basis for judgment. He then offered two options: figure out how to reliably enforce the rule, or abolish the requirement. The claim that the tag is not a useful signal is Corbet's assessment, however, and was not presented as an official conclusion of the summit.
For a self-reported tag to work effectively, there must be a mechanism to verify the information submitted. Even if a tag is missing, a maintainer who checks can point out the omission. But if little checking takes place, the absence of a tag is no proof that AI was not used. Corbet's point was that the latter situation is spreading.
On the other hand, some maintainers had used the tag as a review aid. On October 13, Laurent Pinchart asked for an explanation in a patch review because the Assisted-by tag was missing, and said that when he asks whether it was merely forgotten, he often gets no reply. However, he sees little value in keeping the tag in Git's commit history itself, and proposed having the explanation of AI use written in the cover letter. This proposal reportedly drew little support.
According to LWN's record, Torvalds favored removal because a tagging requirement could discourage people from using LLMs. He also reportedly thought that quite a few submitters feel embarrassed to admit they use AI. Shuah Khan, on the other hand, argued that the tag is still useful. Even so, Corbet recorded that across the room, a strong consensus formed that the tag had outlived its role and the requirement could be abolished.
That said, the interest in understanding how AI is being used has not disappeared. At the summit, some also wanted to know which models were used and what AI-assisted development steps were involved, and it was suggested that such information go in the cover letter rather than the commit message. What has gone is the obligation to disclose via the specific Assisted-by tag; explaining how AI was used has not itself become unnecessary.
Torvalds's own AI-assisted patch: up to 23x faster, and under what conditions
On October 13, Torvalds posted a patch series improving memory-page reference-count handling to the Linux Kernel Mailing List (LKML) and linux-mm. Given that LLM use would be a major topic at the Maintainer Summit, he said he decided to try actually solving a long-standing problem with help from an LLM. The target was a problem in which, when many CPUs read a file at the same time, page reference-count handling becomes a performance bottleneck. The effect was especially large in read paths such as ordinary pread().
This improvement, made up of 10 patches, was confirmed in tests on a Ryzen Threadripper to deliver up to 23x better performance. Torvalds himself, however, cautioned that the result was obtained under very artificial conditions. In the test, all CPU threads repeatedly read a small region within the same page, and he explained that the improvement in real applications would be far smaller.
The cause of the problem was that many CPUs frequently update the reference count of a folio present in the page cache. A folio is a unit for managing one or more contiguous pages of memory. In an ordinary read(), the folio's reference count is incremented while it is being read and decremented when the work is done. But when many CPU threads read the same folio, each CPU repeatedly tries to update the cache line holding the reference count, increasing the load of maintaining cache coherence between CPUs. As a result, 64-thread read performance had plateaued at about 13.3 million operations per second.
Torvalds's proposal is to mark frequently read folios specially and delay their release until an RCU (Read-Copy-Update) grace period has elapsed. RCU is a mechanism that allows the release of data to be deferred to a safe point without stopping the readers. Using the fact that the folio's release is delayed, reads can be completed under RCU protection as long as no page fault occurs. This makes it possible to skip the reference-count increments and decrements that were previously necessary, reducing contention from multiple CPUs rewriting the same cache line. In measurements, 64-thread read performance rose from about 13.3 million to about 304 million operations per second.
Interestingly, Torvalds himself also used AI to write the commit messages. He admitted that the messages came out a bit more verbose than if he had written them himself without the tool, while saying that might even lead to a better result. At the least, he showed an attitude of explaining how AI was used and the verification conditions, rather than hiding its use.
Regarding the earlier noref-filemap-read-with-llm branch, Phoronix described the commit message contents on October 11. According to it, the code, test program, review used for performance comparison, and the first draft of the explanatory text were generated by the AI coding assistant tool "Claude Code" under Torvalds's direction, and performance measurements were run on his own machine. The October 13 mailing-list post, however, does not mention the product name Claude Code. That post, besides stating the fact that an LLM was used, has Torvalds himself explaining in detail the measurement conditions and his earlier trial and error. Compared with simply adding an Assisted-by tag, this gives reviewers more information to base judgments on.
According to LWN's summit record, Torvalds had never used an LLM for kernel development until the week before the gathering. He also explained that it took six months to set up a working environment so that the AI would not return inappropriate responses. After such preparation, he began trying to use AI for an actual performance improvement.
Then, on October 19, Kiryl Shutsemau of Meta posted an 18-patch RFC (request for comments) series reworking Torvalds's proposal. For measurement, he used a 64-vCPU KVM guest running on a Threadripper 7975WX, with 64 threads repeatedly doing 16-byte pread() calls on an ext4 filesystem. The result was that read performance rose from 15 million–15.7 million per second to 68.9 million–70.1 million per second. CPU vulnerability mitigations were left enabled at their default settings.
However, this result cannot be compared directly with Torvalds's improvement of up to 23x, because the test environments and the patch implementations differ. Even so, it confirms that a proposal created with LLM assistance was reworked by another developer and measured anew, folded into the normal kernel development process.
What matters in these cases is not just the fact that AI was used, but that what was changed, why performance improved, and under what conditions it was measured are all explained. Even if code is AI-generated, when developers understand the intent and behavior of the change and can show the measurement conditions, reviewers can more easily verify its technical soundness. For Japanese developers submitting AI-assisted patches to the Linux kernel, too, it will be important to explain concretely the reason for the change and the verification method, not just whether a tag is present.
Should humans write commit messages? The summit consensus and Torvalds's view
The removal of the Assisted-by tag has also kept alive a debate about how to ensure transparency in AI use. On October 13, Laurent Pinchart expressed dissatisfaction with removing the tag without providing another disclosure method. He further suggested that the Linux kernel could adopt a policy like that of the Mesa project, which requires commit messages to be written by humans themselves. His thinking was that if developers who claim AI has raised their productivity still manage the whole development process themselves, the burden of writing commit messages by hand should be small.
Kees Cook, in response, agreed with the principle that humans should write commit messages, but pointed out that, like the Assisted-by tag, such a rule would be hard to enforce. He also explained that his own commit logs are the result of collaboration between himself and an LLM. His position was that using AI as an aid in writing and developers taking responsibility for what they write are not necessarily incompatible.
Pinchart countered that if rules were not to be set merely because they can't be enforced, then the Signed-off-by requirement would be unnecessary for the same reason. Kernel development has many rules that are technically hard to enforce fully, yet he argued there is still value in spelling out the behavior expected of developers. Especially now, with AI use spreading, he said it is necessary to make clear what is being asked.
This rebuttal contains an important point for thinking about why the Assisted-by tag was removed. If difficulty of enforcement were the only reason, it would be hard to explain the difference from other self-reporting-based rules. The difference between the provisions that remain and the one removed likely lies not only in whether they can be enforced but in what they are meant to confirm. The Assisted-by tag shows the tool used in development, whereas Signed-off-by and the provision requiring that patches be explainable are meant to confirm the submitter's responsibility and understanding. This, however, is an interpretation drawn from the discussion as a whole, not an explanation officially given by the summit.
Torvalds replied directly to Pinchart's proposal the same day, questioning the idea that AI should not be used for certain tasks. With irony, he said it is no different from saying not to use a compiler when submitting patches, or not to use an editor to write commit messages. What he expects of developers, he said, is to do their best and understand what they are doing, and that understanding has little to do with the tools used. The point is not whether AI was used, but whether one can understand the work product and submit it responsibly.
LWN's record, meanwhile, says there was a broad consensus at the Maintainer Summit that commit messages should be written by humans even if the code was LLM-generated. Yet Torvalds himself, regarding the patch series he posted five days later, explained that using the tool made the commit messages more verbose. And in his note to Vaughan-Nichols, he called the argument that AI should not write commit messages misguided. While acknowledging it as a well-intentioned opinion, he expressed the view that he wants capable developers to actively use AI as a tool.
In short, the thinking said to have been shared at the summit emphasizes humans writing commit messages, while Torvalds's own practice and statements lean toward accepting AI assistance in writing. However, the consensus recorded by LWN is not a formal rule and includes Corbet's interpretation of the meeting. The view of Torvalds relayed by Vaughan-Nichols is also a quotation from a private note addressed to him. Torvalds's patches state clearly that AI was used and do not run counter to the rule change.
As of now, Linux kernel documentation contains no explicit provision that commit messages must always be written by hand by humans. generated-content.rst asks for transparency about the origin of AI-generated content and for submitters to understand and be able to explain their patches, but it does not limit the authorship of commit messages to humans. While the provision allowing rejection of submissions whose content isn't understood remains, how much disclosure and how adequate an explanation to require is largely left to individual maintainers' judgment.
Coping with a surge of AI-generated patches: responsibility that outlasts the tag
In his note to Vaughan-Nichols, Torvalds named two problems that have surfaced with the spread of AI. One is that AI now finds real bugs in large codebases, adding even more work for already busy maintainers. The other is that some people have AI generate patches and post them without sufficiently understanding the code. He believes that both are not so much caused by AI itself as existing problems that AI has made visible.
On the latter in particular, Torvalds said that while he does not intend to hinder developers trying to learn new technology, he wants to curb "drive-by patches" from people who take no responsibility for follow-up after posting, and submissions whose aim seems to be sending patches for their own sake. The issue is not whether AI was used, but whether the poster understands the content and can handle the subsequent review and revision.
Behind these concerns is the growing number of new contributors participating in kernel development. According to Corbet, Linux 7.3 had nearly 800 first-time contributors. In LWN's record, Torvalds saw the problem as an increase in patches from people who don't sufficiently know how the kernel works, and argued that it is not appropriate to blame LLMs alone. As countermeasures, he mentioned delaying Sashiko's AI-review reports by 24 hours and lowering the review priority of such submissions. He also indicated that the time has come to raise the bar for new contributors submitting code. He answered Pinchart's question by confirming that there is no intention to exclude developers who do not use AI.
Greg Kroah-Hartman has also given an outlook on the rise in AI-generated bug reports. He expects a flood of bug reports for the next 18 months or so, after which many bugs will have been fixed and things will settle down. This is his own forecast, however, and whether the burden actually eases in that period will only be known as events unfold.
In the first place, the Assisted-by tag was not created as a countermeasure to mass bug reports or low-quality patches. For patches submitted without understanding their content, the provisions that a human signer bears responsibility, and that unexplainable changes can be rejected without detailed review, continue to apply. Maintainers also retain discretion to request additional testing or lower review priority. If the practice of explaining how AI was used in cover letters spreads, it would also lead submitters themselves to supply the information needed for such judgments.
The removal of the Assisted-by tag requirement has already been merged into mainline for the upcoming Linux 7.4. Going forward, attention will be on the finalized documentation in the official release and on how far the practice of explaining AI use in cover letters takes hold. Debate between developers and maintainers may also continue over using AI to write commit messages.
This change does not mean the Linux kernel has unconditionally loosened its conditions for accepting AI-generated code. If a human does not bear responsibility through Signed-off-by and cannot understand and explain their submitted change, the patch may be rejected without detailed review. While maintaining this principle, what the kernel emphasizes is shifting from declaring the fact that an AI tool was used to the substantive check of whether the submitter understands the work product and can explain it technically.