The 7.1 kernel merged 15,849 changesets from a record 2,479 developers, but only about 51% carried a Reviewed-by tag and about 8% a Tested-by tag — both lower than recent releases. Producing kernel code is no longer the hard part. Reviewing it, and testing it on real hardware, is. For an embedded engineer with a board on the desk, kernel patch review is the part of the job hardest to replace.
The advice for an engineer who wanted to be taken seriously upstream used to be simple: send patches. It still works, and we covered the mechanics in How to Get Your First Linux Kernel Patch Accepted. But the ground under it has moved. The supply of kernel patches has risen sharply, and the supply of people able to judge them has not. Kernel patch review is where the shortage sits now.
The numbers: more patches, less review
Jonathan Corbet’s development statistics give hard figures. The 7.0 kernel, released on 12 April 2026, took 14,251 non-merge commits from 2,362 developers — at the time a record. Reviewed-by tags appeared on 54% of those commits, Tested-by on 9.4%.
The 7.1 kernel, released on 14 June 2026, took 15,849 non-merge changesets from 2,479 developers, beating the record 7.0 had just set. Reviewed-by tags fell to almost 51% and Tested-by to nearly 8%, both of which Corbet calls relatively low compared to recent releases. Volume went up; the share anyone reviewed or tested went down.
One more figure explains much. In 7.0, 31 commits carried an Assisted-by tag, which marks the use of a coding assistant. In 7.1, 299 did — and Corbet notes the real number must be higher, because many developers are not complying with the disclosure rules.
Why kernel patch review became the bottleneck
First-time contributors tell the same story: 489 in 7.0, a record, then 530 in 7.1. Corbet attributes the climb almost entirely to the growing availability of LLM-based tools. The community is not short of contributors. It is short of judgement.
The most prolific 7.1 first-timer contributed 60 commits across the SMB filesystem, SCTP, Bluetooth, io_uring, SCSI, amdgpu and RDMA RoCEv2, almost all carrying Assisted-by tags. Corbet’s comment is the one to sit with: few kernel developers could make substantial changes across that much of the kernel, and whether any could fully understand patches to that range is a different question.
Maintainers are responding with tooling. At the 2026 LSFMM+BPF summit, Roman Gushchin and Chris Mason presented Sashiko, an LLM-based reviewer now running on the linux-kernel list and 47 others that opted in. Across 1,500 threads it showed roughly 10% false positives, 85% true positives, and close to 97% accuracy on critical and high-severity problems. But Chuck Lever reported resending an 18-patch series seven or eight times, because Sashiko kept finding different problems each pass. Automated review adds throughput; it does not add a person who will say “I have checked this and I stand behind it.”
Your move → Pick one subsystem you actually ship, not one you find interesting. Subscribe to its list and read every posted series for a month before you send anything of your own.
Tested-by is the tag that needs your board
Read the kernel’s own definition carefully. A Tested-by tag indicates that the patch has been successfully tested, in some environment, by the person named. That is all it claims, and that is why it matters.
Roughly 8% of 7.1 commits carried one. The top credited tester in that cycle, Daniel Wheeler, supplied 89 of them himself — 5.8% of every Tested-by tag in the release. When one person accounts for almost six percent of all the testing credit in a kernel release, the field is not crowded.
A language model cannot produce a Tested-by tag. It has no board. It cannot power up an i.MX or a K3 platform, load the series, and observe that the clock tree is now wrong on your specific hardware. You have the one input the upstream process cannot synthesise: physical hardware, powered on, running the actual patch.
Pull the series, build it for your target, and boot it:
raghu@techveda.org:~$ b4 shazam 20260714-fix-foo-v2-0-0123456789ab@example.com
raghu@techveda.org:~$ make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- -j"$(nproc)" Image dtbsThen reply with a tag that names your environment:
Tested-by: Raghu Bharadwaj <raghu@techveda.org>
# Booted on i.MX8MP EVK, 7.2-rc2, exercised the I2C bus at 400 kHz
# across 200 suspend/resume cycles. No regression observed.Your move → Boot the next -rc on the board next to you and reply to one series with a Tested-by tag stating the board, the kernel version, and what you exercised. Specific tags get you remembered.
The kernel has written down who is accountable
This is not a matter of opinion. Documentation/process/coding-assistants.rst is direct: “AI agents MUST NOT add Signed-off-by tags. Only humans can legally certify the Developer Certificate of Origin (DCO).” It makes the human submitter responsible for reviewing all AI-generated code, adding their own Signed-off-by, and taking full responsibility. Attribution has a defined format:
Assisted-by: AGENT_NAME:MODEL_VERSION [TOOL1] [TOOL2]The patch submission guide adds that if you used any sort of advanced coding tool, failure to add an Assisted-by tag may impede acceptance of your work. The tool writes, but a named human with a real email address carries the consequences.
Reviewed-by carries the heaviest version of this. By offering it you formally state that you carried out a technical review, that your concerns were resolved, and that you believe the patch is free of known issues arguing against inclusion. That is a professional signature, and it is in short supply.
How to build kernel patch review credibility
- Narrow your scope. One subsystem, chosen because your product depends on it. Find the right people and lists from the patch you care about:
raghu@techveda.org:~$ scripts/get_maintainer.pl 0001-my-fix.patch - Read before you write. Most of what you learn about review, you learn by watching maintainers review others.
- Test other people’s work. The fastest way to become useful to a maintainer.
- Report regressions properly. When something breaks, bisect it rather than describing it:
raghu@techveda.org:~$ git bisect start raghu@techveda.org:~$ git bisect bad v7.1 raghu@techveda.org:~$ git bisect good v7.0Then report it with a Fixes: line naming the offending commit and a Closes: line pointing at the public report.
- Offer Reviewed-by only when it is true. An honest “I tested this, I did not review the locking” is worth more than an inflated tag.
This is where formal study pays back, because you cannot review what you cannot read. Our Linux Kernel Infrastructure program is built around reading and reasoning about real kernel subsystem code.
What this means for your career
The 7.1 cycle was supported by 230 identifiable employers, and at least 132 first-time developers already had one: Qualcomm brought in 15, AMD 14 and Google 12, across 51 companies. Companies are actively placing people into upstream work. What they cannot easily buy is an engineer whose judgement is on the public record.
And it is permanent. Every Tested-by, Reviewed-by and Reported-by tag you earn is written into the kernel’s git history, attached to your name, searchable by anyone:
raghu@techveda.org:~$ git log --grep="Tested-by: Raghu Bharadwaj" --onelineFor engineers in India working on proprietary products, this matters. Most of what you build is under an NDA and can never be shown to anyone. Your upstream tags are the one part of your work you fully own and can show to any employer.
Your move → Set a target you can verify at year end with one command: a number of Tested-by tags on hardware you own. Three real ones beat thirty typo fixes.
Key takeaways
- 7.1 set records for changesets (15,849) and developers (2,479), while Reviewed-by coverage fell to almost 51% and Tested-by to nearly 8%.
- Disclosed tool-assisted commits went from 31 in 7.0 to 299 in 7.1. Generation scaled; review did not.
- Automated reviewers add throughput but not accountability. Only a human can sign off.
- Tested-by requires physical hardware, which embedded engineers have and no tool can supply.
Frequently asked questions
Can I offer a Tested-by tag if I am not an expert in that subsystem?
Yes. A Tested-by tag only states that you successfully tested the patch in some environment. It does not claim you reviewed the code. State exactly what you tested and on what hardware.
What is the difference between Tested-by and Reviewed-by?
Tested-by says the patch was successfully tested by the person named in some environment. Reviewed-by is stronger: that you carried out a technical review, raised and resolved your concerns with the submitter, and believe the patch is free of known issues that would argue against including it.
Do I have to disclose that I used an AI tool on a patch?
Yes. The kernel documentation requires an Assisted-by tag if you used any sort of advanced coding tool, and states that failure to add it may impede acceptance of your work. It also forbids AI agents from adding Signed-off-by tags, because only a human can certify the Developer Certificate of Origin.
Further reading
- Development statistics for the 7.1 kernel — Jonathan Corbet, LWN.net, 15 June 2026.
- Development statistics for the 7.0 kernel — Jonathan Corbet, LWN.net, 13 April 2026.
- Reviewing kernel patches with LLMs — Jake Edge, LWN.net, 25 May 2026.
- Submitting patches — Tested-by and Reviewed-by definitions, and the Reviewer’s statement.
- AI Coding Assistants — the Signed-off-by rule and the Assisted-by format.
- b4 end-user documentation — applying patch series from lore.
- How to Get Your First Linux Kernel Patch Accepted — the companion piece.
