The Linux 7.3 networking pull request landed on August twentieth, and the number that matters is not in the diffstat. Jakub Kicinski and Paolo Abeni merged 632 patches through net and 648 through net-next, and Kicinski estimates that a third to a half of the net-next side looks like AI generated low priority fixes, cleanups and clarifications. His summary of the situation is four words long: we are completely overwhelmed. The response is the interesting part. Rather than closing the door on machine written patches, netdev secured an LLM budget from Meta and now runs every patch past several frontier models before a human spends attention on it.
The short answer
The Linux 7.3 networking merge window closed on Thursday, August twentieth, 2026. Jakub Kicinski and Paolo Abeni merged 632 net patches and 648 net-next patches, and Kicinski describes the maintainers as completely overwhelmed by AI generated contributions. Netdev is not banning them. It has secured LLM budget and access from Meta, runs each patch past several frontier models to strip out hallucinations, and plans to hand routine process work to the models next cycle.
Most kernel pull requests tell you what was added. This one tells you what it cost to accept it, which is rarer and considerably more useful if you maintain anything that strangers send patches to.
The number behind the number
Kicinski opens with what he calls a quick and dirty count: a very similar number of patches through net (632) and net-next (648). Split between two maintainers across a merge window, that is a normal quarter for the largest subsystem in the kernel.
Then he adds the qualifier that makes it abnormal. One third to one half of the net-next patches, in his reading, look like AI driven low priority fixes, cleanups and clarifications. Not wrong. Not malicious. Just work that nobody asked for, arriving faster than the people responsible for it can read.
His summary is four words: we are completely overwhelmed.
That sentence carries weight because of where it comes from. Netdev is one of the best resourced subsystems in the tree, with full time maintainers paid by companies whose businesses depend on the code being correct. If the review pipeline strains there, it is not the kind of problem a bit more funding solves.
Why this cannot be fixed by saying no
Two other projects reached the opposite conclusion this month. Greg Kroah-Hartman closed drivers/staging to LLM written patches because staging exists to teach humans, and the easy cleanups are the curriculum. The GCC Steering Committee declined legally significant LLM derived contributions on copyright grounds. Debian is voting on eight different ballot options for the same question.
Netdev cannot take either exit cleanly. A one line fix to a driver error path is not legally significant, it does not teach anyone anything, and if it is correct then rejecting it means shipping a known defect on principle. The subsystem already tried reducing the surface instead, dropping old networking code and drivers that nobody running a current kernel is likely to use, specifically to cut the volume of noise arriving against them. The patches kept coming.
So the remaining move is to make review cheaper per patch rather than to make patches rarer.
Multiple models, one patch
The mechanism Kicinski describes is straightforward. Netdev secured sufficient LLM budget and access, with a credit to Meta, to run reviews with multiple frontier models on each patch. Running several independent models over the same diff and comparing what they flag is a reasonable way to filter hallucinated findings, because a defect that only one model sees is usually a defect that does not exist.
He is careful about the limits, noting that in terms of review the LLMs can only do so much.
The more interesting admission follows. The netdev APIs, he says, especially for rare events such as PCIe errors and timeouts, have always been racy, and now LLMs do not let the maintainers ignore that. Models reading the whole tree at scale surface every theoretical race a human reviewer had learned to walk past. Individually those reports are often defensible. Collectively they are a denial of attention, because the cost of deciding that a race is unreachable in practice is nearly the same as the cost of fixing one that is not.
What changes next cycle
The direction Kicinski sketches is a shift from using models to review code toward using them to run the process:
- managing patchwork, the tracking system where netdev patches queue for attention
- automating the common process complaints that maintainers currently type by hand
- editing commit messages
- possibly applying patches that already carry a reviewed-by tag from someone the maintainers trust
Read that last item slowly. It puts a machine on the commit path for changes a trusted human has already signed off, which is narrower than it first sounds but still a threshold the kernel has not crossed before.
The features, since they did ship
The core stack gained BIG TCP support inside UDP tunnels via the VXLAN and Geneve drivers, which matters if you run overlay networks and have been leaving offload gains on the table at the tunnel boundary. MPTCP handles extreme memory pressure better.
On wired drivers, there is initial CXL support for AMD and Solarflare NICs, firmware flashing support for AMD Pensando NICs, and the first skeleton of the Intel iXD driver. That last one exists to support the Intel Control Plane PIC Function on E2100 and later IPUs and FNICs, and for 7.3 it is infrastructure only, so there is nothing to test yet unless you have the hardware and a taste for early driver work.
Wireless picked up more Multi Link Operation work, the new mm81x driver for Morse Micro long range S1G devices, NXPWIFI for NXP hardware, and MT7928 plus MT7925 NAN support in MT76.
What we would take from this
If you maintain anything public, the netdev experience is a preview rather than a curiosity. The failure mode is not bad patches, it is defensible patches at a rate that exceeds human review, and policy bans only work where you can justify refusing correct code.
The practical lesson underneath is the one about racy APIs. Netdev is not being punished for sloppiness. It is being audited by tireless readers against interfaces that were designed when nobody could afford to read everything. Any codebase with quiet assumptions in its error paths sits in the same position, and the audit is already running whether or not the reports have reached you yet.
Sources and further reading
- Linux 7.3 Network Changes Merged But Developers Completely Overwhelmed Due To AI/LLMs, Phoronix, August 20, 2026
- Discussion thread on the Linux 7.3 networking pull request, Linux.org
- Kicinski: netdev in 2023, LWN.net
Frequently asked questions
How many patches actually went into Linux 7.3 networking?
Kicinski gives a quick and dirty count of 632 patches merged through net, the fixes tree, and 648 through net-next, the feature tree, for a combined 1,280 across the cycle. He splits that work with Paolo Abeni. The raw number is not extraordinary for networking, which is routinely one of the largest subsystems in any kernel release. What is new is the composition: he estimates a third to a half of the net-next patches look like AI driven low priority fixes, cleanups and clarifications rather than work someone needed for a machine they actually own.
Is netdev rejecting LLM generated patches like other subsystems?
No, and that is the split worth noticing. The staging tree and GCC both took the policy route and declined machine written contributions. Netdev has gone the other way. It cannot refuse patches that are individually correct, so instead it has industrialised review: several frontier models look at each patch first, which Kicinski says eliminates some hallucinations before a maintainer reads them. The plan for the next cycle goes further, moving routine process work onto the models as well.
What does Meta have to do with kernel networking review?
Kicinski credits Meta for the LLM budget and access that make multi model review possible, and he works there. Running several frontier models over more than a thousand patches per cycle is a real inference bill, and the maintainers have no mechanism to pay it themselves. It is worth being clear about what that arrangement is: a corporate sponsor now funds the review capacity that keeps a core kernel subsystem moving, which is a new kind of dependency for the project even though the review decisions stay with the maintainers.
What is the point about racy APIs?
Kicinski says the sad truth is that netdev APIs, especially around rare events such as PCIe errors and timeouts, have always been racy, and that LLMs no longer let the maintainers ignore that. Models reading the tree at scale find the theoretical race conditions that humans have quietly stepped around for years. Most of those reports are individually valid and practically irrelevant, which is exactly what makes them expensive. Someone still has to read each one to work out which category it belongs to.
Which networking features actually shipped this cycle?
BIG TCP now works inside UDP tunnels through the VXLAN and Geneve drivers, MPTCP handles extreme memory pressure better, and the core stack picked up other improvements. On the driver side there is initial CXL support for AMD and Solarflare NICs, firmware flashing for AMD Pensando NICs, and a skeleton Intel iXD driver for the Control Plane PIC Function on E2100 and later IPUs. Wireless gained continued Multi Link Operation work, an mm81x driver for Morse Micro long range S1G devices, a new NXPWIFI driver, and MT7928 plus MT7925 NAN support in MT76.