If you're on the kernel mailing list (LKML), aren't you concerned about AI? Would you be interested in joining the discussion?

Project Discussion
1

Dear person reading who is perhaps on the kernel mailing list (LKML),

I’m surprised to see nobody else spoke up here yet: Making sure you're not a bot! It seems like previously there was no systematic and sourced list of wider concerns with AI and nobody requesting the kernel developers address them. I tried to fill this gap, but it seems like people gotta jump in to bring attention to it, to get any response.

I have seen hints that part of the sentiment might be that the kernel team is using AI just to rewrite own code and backport patches, avoiding the plagiarism part. But:

  1. The data seems to suggest that this may not be true: Linus Torvalds declares massive AI-fueled code surges as the new normal for Linux - Neowin There is so much more new code, it seems unlikely this is just backporting and rearranging.

  2. The data on plagiarism doesn’t seem to suggest to me that rewrite prompts are necessarily safe from training data injections.

  3. The kernel’s LLM policy doesn’t actually seem to say that backporting patches and rearranging existing code is the only allowed use.

    (Edit: I’m not saying that is my favorite solution, I’d rather have AI code out of the kernel and have it limited to review without code proposals, but it’d at least have backed up that sentiment.)

I would be happy to see more people join the discussion on the LKML.

Regards,

Ellie

PS: Sorry if I’m posting this in the wrong section.

1 Like
2

I think this should be in the water cooler. Its not a Fedora project topic in my view.

1 Like
3

It could be, but given we also have a much-discussed Initiative proposing that we ship an LTS kernel, both have something in common:

Fedora struggles with validating kernels and stopping regressions from happening. What this post highlighted is that the rate of change in the kernel in ramping up, thanks to AI, and related to that, the rate of CVEs being filed is also going up.

We can’t carry on as we are right now - ideally we get more kernel maintainers, better testing, and maybe for those who don’t want to be on the bleeding edge we can then also support an LTS kernel. Wearing my work hat, I’d rather not deal with kernel regressions during the lifetime of a Fedora release, and I know many users who don’t (and the team that internally supports Fedora certainly doesn’t)

3 Likes
4

I don’t disagree. But I would also assume that the “extreme” we currently experience is a temporary phenomenon as far as it concerns CVEs etc.

We have now more knowledge than before, and as such, it can show us what we have not seen before, throughout everything that we have created before. It’s now all sub systems of the kernel with all their code that need to be processed by this new knowledge to bring them to the current state of knowledge.

In the military, this is a more rationalized phenomenon: at some point, someone found a way to better penetrate their tanks’ armor by some new technology. When it happened the first time, they learned their tanks need adjusted armor. The clue: they did not need to add adjusted armor to the tank damaged, but to all tanks in their army.

For us, armor is testing, and the many tanks to upgrade are our sub systems etc. It surely will take some time until the kernel is “covered” throughout. But my expectation (or, hope?) is that things become smoother once all parts of the kernel have been widely AI-reviewed, and/or tested otherwise for new means of disruption enabled by new AI etc.

Adding AI means optimally to our testing is a very good idea though, and maybe a dependency to get rid of these phenomenons over time. The new knowledge must be applied before release, not after. Imho, that part might be the most important discussion. That said, not sure if we need a dedicated maintainer for this, or another one for the kernel, or both, or neither?

Regarding the main topic here, I don’t want to underestimate the implications of AI in mailing lists → I experienced it here in Discourse many times, and the AIs get more and more people into conversations before they are discovered, etc etc. How big that can prove as an issue (plus code they can submit) for LKML, I think I am too passive in LKML to make a guess…

1 Like
5

My guess is that no one responded to your email on LKML because there is no desire to re-litigate/re-debate this policy after it was already debated for months and they agreed on the current policy as a middle ground. Concerns like this probably come up every once in a while, but while I was not part of the months-long debates around what the LLM policy should be, I imagine these points were considered.

(Personally, though, I think you raise some fair points.)

1 Like
6

From the kernel folks I do talk to, most of them don’t consider the longterm series to be better than the stable kernel series (which is what Fedora currently ships). Several of them actually say that longterm kernels are of worse quality, and would prefer people not use it because there are far fewer people actually paying attention to them, and lately the way changes are getting shipped into longterm kernels creates even more regressions than what goes into stable kernels.

I think we’d be signing ourselves up for much more pain with the longterm kernels. Even the stable kernels that “become” longterm ones have been worse in my experience, so I usually like it when we upgrade out of those versions.

5 Likes
7

Timeliness is always a factor when raising concerns. Being late with raising them, doesn’t invalidate them, but it does impact the level of consideration that should be expected.

Given that a policy decision was already made, after significant discussion, the discussion should now focus on concern mitigation strategies.

Just as an example, anyone who is legitimately concerned about the issue of plagiarism should be asking questions about what scanning tools are being used already to scan the kernel looking for human plagiarism as a way to baseline how often code is structurally similar enough to other existing code to rise to a legitimate concern. While its reasonable to conclude that the AI assisted workflows raise the likelihood of it happening, that new found awareness that it might be happening more frequently with AI assisted workflows doesnt change that fact that it could be happening already in unassisted workflows. So understanding what scanning tools are employed or could be employed to mitigate that risk regardless of whether the commits are AI assisted or not should now be the focus of that concern. How does the kernel development identify and derisk human plagerism? Answer that question and you probably have identified the mitigation strategy for AI assisted development risk.

The technical quality concerns are similarly likely mitigated by the use of scanning tools in the CI/CD workflows that should already be in place looking at unassisted commits made by humans. I’m pretty sure there are static analyzers employed already. If AI slop is as sloppy as people expect, I would expect the analyzers should catch the AI slop as easily as it would catch my human generated slop.

8

I personally think it’s a backward approach. Even if it worked, and with plagiarism testing services apparently being notoriously unreliable I assume it won’t, this is putting out the fire after you watched the arsonist without intervention.

Establishing coying things without atribution as normal seems toxic for FOSS and that seems like the actual issue, not the cleaning up of the fallout afterward.

9

I should add that the timeliness points are totally fair. However, I emailed the Linux Foundation a long time ago given I’m not a kernel developer. But it doesn’t seem like they’re reading any of their e-mail.

10

I think the piece you’re probably missing is nobody reads linux-kernel@ anymore. In order to reach kernel developers, you have to email the respective subsystem mailing lists.

2 Likes
11

Afterwards? Who’s talking about afterwards?

If you’re seriously concerned about plagiarism in open source software, then I would suggest you take a look at what the state of the art is in academic publishing for plagiarism detection. In academic publishing, journal editors have had access to professional plagiarism scanning tools for something going on 20 years now…well before the current wave of generative pre-trained transformer based LLM-based tools were available.

Academic journal editors have use scanning tools for years as part of the submission process that also includes human peer review. The humans in the peer review process are chosen as subject matter experts for the research content of the paper…they aren’t expected to have read the tens of thousands of papers that might have been plagiarised. Even arXiv has begun to use thse tools, since 2016 i believe, and arXiv is not a peer reviewed corpus of work, arXiv is just self-published pre-prints.

Thought experiment time.
You are maintaining a software project and I submit a well formed and functional pull request. How do you check that my human generated commit isn’t plagiarising another human’s work? What new thing are you going to do that the academic publishing industry isn’t doing right now?

The issue of human plagiarism in academic publishing has been a material and significant concern for decades…scanning tools are the state of the art in that space. While software development will need tools trained on entirely different content, I see no reason why those two fields can’t share a common methodology with regard to plagerism detection as part submission review.

If you have a better idea, you could probably publish your research on plagiarism prevention at arXiv and get feedback on your proposed better methodology. Just make sure you cite the existing peer reviewed published research done in the area so you don’t get flagged by the plagerism scanners deployed there.

12

My question is this:

How on earth is anyone expected to communicate on these mailing lists, when they are filled to the brim with commits? Am I missing something??!? I can keep scrolling on to the next page over and over, and still not manage to reach mail from the previous day.

@ell1e, how on earth did you find this mail? Were you the one who emailed it?

EDIT

I read the author, and it turns out that it is you.

There are reasons to be very concerned about the state of mailing list communications as of current. The sheer amount of commits is guaranteed to drown out any discussion attempts made, whether they are important, or otherwise.

For this reason, I don’t have any real way of communicating with Kernel developers, since their mail inbox is likely going to be drowned with commits, especially from AIs.

The whole communication with kernel developers thing is still a mess, even if you mail to a subsystem list.

What on earth is going on here?

13

no idea. There have been over 1k posts to lkml per day now for years…I’m assuming people make use of a lot of machine learning filtering and scoring in their clients to help bubble up patches they are interested in.

2022 the monthly average for the entire year was 36k+ posts to lkml per month.
2022 Q1 (Jan-Mar inclusive) monthly average for the entire year was 35k+ posts to lkml per month.
2023 Q1 35k+ monthly average
2024 Q1 33k+ monthly average
2025 Q1 40k+ monthly average
2026 Q1 49k monthly average

2020 Q1 33k+ monthly ave

For those interested in finding the full mailing list discussion about the linux kernel policy…for research reasons… The mailing list discussion concerning the documentation change spanned 6 proposed versions of the policy draft and occured in the Oct 2025 - Jan 2026 timeframe,

Here’s a search result that i think captures the discussion in the context of the proposed documentation change. The results are newest first, but if you scroll down you’ll find the first draft of the proposed policy.

14

This is also a fun search…

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?qt=grep&q=Assisted-By

I fully expect commits with Assisted-By defined to grow as a percentage of commits as employed kernel contributors become more proficient with the tools available to them. Corporate developers authored 84.3% of kernel commits in 2025. its not unreasonable expect to see commits from that pool of contributors to all eventually have assisted-by tags on their commits.. its just a question of how quickly that happens.

It’s gonna be an interesting discussion when the contributor stat summaries for 2026 come out. The trend graph for the assisted-by tag will be fascinating. I’m very interested in whether its going to end up being used in merged commits by both corporate and volunteer contributors in statistically equal measure.

15

For reference, Linus’ stance on AI in the kernel: Subject: Re: Linking Patchwork with Sashiko?

16

Yes. A lot of people are concerned, but I think the reality is we only hear from people who aren’t concerned because unfortunately a lot of those people have gone into a “this is the future no matter what” corner where they don’t really want to talk about any of the concerns around these tools. The bubble is still popping, but that’s not something we’re going to talk about until it pops very violently in people’s faces apparently.

I don’t see LLMs going away in the future, but I absolutely 200% see tools like claude, gemini, etc. disappearing because in four years they still have yet to actually reign in profits. It’s just not sustainable, and we are already hitting the peak of what models are capable of. but I do see them being used in more sensible workflows that are not attempting to write code through LLMs, but using them for things they’re actually meant for like research and analysis (code review falls into this category, imo). At least in the kernel. Elsewhere, I’m not going to try and guess.

However, I’m not sure I see this happening until the economy crashes. A lot of people are locked into this mindset that you can experiment with anything and then use your own experiences to rate its usefulness, without realizing this is the first time in the industry where we’ve had a tool which is - according to all studies regarding how humans interact with chat bots - literally preventing us from reasoning with it in the same way we do actual tools because subconsciously, no matter how many times we tell ourself otherwise it does have an effect on one’s ability to reason. E.g. this is the first time this really isn’t, actually possible or true. Your subconscious thinks its a person, doesn’t matter what your conscious thinks. That in itself makes measuring the output of these tools incredibly difficult.

Unfortunately, Linus doesn’t seem to understand that last part and frankly it’s why his response is so out of left field and completely off topic from the actual point of discussion in that thread. To be clear: the thread wasn’t about generative AI contributions, it was about sashiko - as pointed out by sashiko maintainers, to linus. I don’t even think a lot of the sashiko maintainers actually agree with him based off the conversations I’ve had with them, the opinion has always been that if these tools aren’t useful we should stop using them.

It is unfortunate though that now we all have to play PR cleanup for Linus :|. But what else is new.