Linux staging tree: Greg Kroah-Hartman blocks paths generated by LLM

Overwhelmed by an "onslaught" of AI-generated patches, the maintainer of the Linux staging tree now systematically rejects contributions generated by LLMs—except for genuine security fixes. Yet, he still uses LLMs himself.

The context: what is the staging tree?

To understand Greg Kroah-Hartman’s (aka gregkh) decision, we need to grasp what the staging tree is within the Linux kernel’s organization. It’s a holding area for drivers and code not yet ready for mainline: insufficient quality, unstable APIs, dependencies to clean up. Historically, it’s also the entry-level for new contributors—where one learns to contribute to the kernel without being a 15-year kernel dev expert.

Greg Kroah-Hartman is the maintainer of this staging tree. He’s the one who reads, arbitrates, accepts, or rejects patches.

What happened

Facing what he describes as an "onslaught"—a deluge—of patches generated by LLMs (Large Language Models), gregkh has just announced a new policy: patches produced by AI will now be rejected from the staging tree.

What makes the decision particularly interesting is what it isn’t: an ideological rejection of AI. Gregkh himself uses LLMs for his own contributions to the kernel, and he openly admits it. What he rejects is the use of LLMs by contributors who lack the skills to evaluate what the model has produced.

The logic is crystal clear: the staging tree is meant to train contributors. Submitting an AI-generated patch without understanding what it does is the exact opposite of that. And it creates extra work for maintainers who must review, correct, and reject low-value patches in ever-increasing volume.

A single exception is granted: patches that fix genuine security issues (genuine security fixes) remain welcome, regardless of origin.

Why this matters beyond the staging tree

This is the most concrete manifestation to date of a tension growing in the free software community for months. On one side, LLMs capable of producing syntactically correct code. On the other, maintainers absorbing a rising volume of shallow patches generated without real understanding of the context.

The Linux kernel isn’t an ordinary codebase. Every line can affect millions of systems. The quality of a patch isn’t just about the code—it’s about the author’s understanding of the why behind the code, the context in which it fits, the side effects it may have. An LLM-generated patch submitted without a qualified human behind it often misses this "why."

This isn’t the end of AI in the kernel—far from it. It’s the beginning of an explicit policy that distinguishes AI as a tool (for a contributor who knows what they’re doing) from AI as a substitute for skill (for someone lacking the basics). The nuance is essential, and gregkh embodies it himself.