While Linux's second-in-command Greg Kroah-Hartman does Greg KH announced on Monday a new policy around AI/LLM usage specifically for the Linux kernel's staging area within
Greg elaborated in his
Outside of the staging area, AI/LLM-generated work continues to be permitted with Linus Torvalds viewing it as a tool and that
use AI / LLMs himselfto success in the Linux kernel, given the "onslaught" of kernel patches produced by large language models and the intent on the Linux kernel's staging area being an area for newcomers to get involved, moving forward he's now rejecting AI/LLM-generated staging patches. But there is one exception and that is for genuinely valid security fixes.Greg KH announced on Monday a new policy around AI/LLM usage specifically for the Linux kernel's staging area within
*drivers/staging/*where LLM-generated patches will now be forbidden unless they address a real security issue.Greg elaborated in his
announcementof this new policy:"Given the recent "onslaught" of LLM-generated kernel patches for the drivers/staging/ subsystem, I'd like to clarify my position going forward with regards to taking patches made with these tools.
First off, drivers/staging/ exists PRIMARILY as a place for new kernel developers to learn how to get involved in kernel development. It contains loads of "low hanging fruit" with regards to code cleanups and api changes, perfect for new developers to learn the process in a safe and friendly way, with no pressure as no one should be relying on the code in these directories (as proof of the TAINT_CRAP flag that gets set if you ever actually load any of this code into your kernel tree.)
We don't just take "fix all the coding style issues in this file!" type of patches that are generated by tools, as that would defeat the whole purpose of drivers/staging in the first place. We could do that tomorrow if we actually cared about the code in here, but rather, we live with the issues just because this is where people can start out and learn and grow from.
So this mean that anyone attempting to use a LLM to cleanup or "fix" any code in drivers/staging/ is EXPLICITLY defeating the whole purpose of it existing in the first place. Because of this, going forward I am going to automatically reject any patches generated with a LLM for the drivers/staging/ subsystem, with one exception noted below.
And yes, it is VERY obvious when people submit LLM-generated patches, so don't think that just not disclosing the use of them will allow you to "get away" with anything here. The goal is for people to be able to learn, not to try to "trick" a maintainer. If anyone is determined to have deliberately "tricked" us, well, consider this your warning ahead of time...
Note, LLMs are very good at finding suspect "security issues" in kernel code these days. But even with the best of the current and next generation tools, at least 1/3 of the results they generate are flat out wrong or harmful. So, if you think your LLM-found/fixed issue in a drivers/staging/ file is really valid, it's fine to submit it BUT you must have first tested it on the actual hardware for the driver, and described how you have done so, in order for us to be willing to take the change. This testing process should hopefully weed out the 1/3 wrong reports, but that isn't always the case, so you MUST be willing to defend your submission and prove that it really is correct in fixing a bug that a user can actually hit.
In other words, drivers/staging/ here is a "gym" that is here to learn and grow your skills with. A LLM is turning into a reasonable tool to do "heavy lifting" for some things but that should only be done by those that have already properly trained their skills to know what type of lifting can be done, and in what way. See this great essay by Bruce Schneier for where he explains this in much better[detail]."
Outside of the staging area, AI/LLM-generated work continues to be permitted with Linus Torvalds viewing it as a tool and that