How to Get Your First Linux Kernel Patch Accepted

For an embedded or kernel engineer, getting your first Linux kernel patch accepted is one of the clearest signals you can put on a CV. It proves you can read unfamiliar code, follow a strict process, and work with maintainers who hold a very high bar. This guide walks through the exact steps to prepare, send, and defend a first patch, using the current kernel.org process. The change itself can be small. What matters is that you complete the full loop correctly.

Why your first Linux kernel patch is worth the effort

A merged patch is public and permanent. Your name and sign-off stay in the Git history of a project that runs on billions of devices. For hiring managers in embedded Linux, device drivers, and BSP work, that is stronger evidence than any certificate, because the kernel community rejects work that is sloppy or untested. The skills you practice here, namely reading code paths, writing a clear commit message, and responding to review, are the same skills that senior engineering roles are built on.

You do not need to invent a feature. Most first contributions are small fixes: a real bug, a correctness issue found by a static analysis tool, or a documented behaviour that the code does not match. The goal of a first patch is to learn the workflow end to end, not to make a large change.

Find a change worth submitting

Pick a change that is small, real, and easy for a reviewer to verify. Each patch must solve exactly one problem and be justifiable on its own. Good places to look for a first change include:

• Warnings from scripts/checkpatch.pl or sparse on a driver you already work with, where the fix is a genuine correctness improvement and not a cosmetic edit made only to silence the tool.
• A real bug you hit on your own hardware, where you can describe the user-visible impact (a crash, a lockup, a wrong value in dmesg).
• The drivers/staging tree, which historically accepts cleanup and fix work from new contributors.
• A mismatch between documented behaviour and actual code that you can demonstrate.

Avoid changes that only reformat code or rename things for taste. Maintainers see many such patches and usually reject them. If you found the bug with git bisect, record the commit that introduced it; you will reference it later with a Fixes: tag.

Your move → Before writing any code, open the MAINTAINERS file and find the subsystem that owns the file you want to change. Note the T: line; it tells you which Git tree to base your work on.

Set up the source tree and your identity

Start from the correct tree. Many changes go to a subsystem maintainer’s tree rather than mainline, so check the MAINTAINERS entry first. To begin from mainline:

raghu@techveda.org:~$ git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
raghu@techveda.org:~$ cd linux

Set your real name and email. The kernel does not accept anonymous contributions, and the name you configure here becomes the author and sign-off in the permanent changelog.

raghu@techveda.org:~$ git config user.name "Raghu Bharadwaj"
raghu@techveda.org:~$ git config user.email "you@example.org"

Create a topic branch so you can later generate the base-commit information that reviewers and automated CI need:

raghu@techveda.org:~$ git checkout -t -b my-first-fix master
Branch 'my-first-fix' set up to track local branch 'master'.
Switched to a new branch 'my-first-fix'

Make the change and write the commit message

Make one logical change, then commit with sign-off. The -s flag adds your Signed-off-by: line, which certifies that you have the right to submit the work under the kernel’s licence (the Developer’s Certificate of Origin). The -v flag shows the diff in the editor so you can review it while writing the message:

raghu@techveda.org:~$ git commit -s -v

The commit message is judged as carefully as the code. Write the description in the imperative mood, for example “fix” and “remove” rather than “fixed” or “this patch removes”. State the problem first, then the user-visible impact, then what your change does. If you are fixing a specific earlier commit, add a Fixes: tag with at least the first 12 characters of its SHA-1 and the one-line summary. A complete message looks like this:

net: foo: avoid use-after-free on probe failure

When foo_probe() fails after registering the netdev, the cleanup
path frees the private data before unregistering, so a queued
work item dereferences freed memory and triggers a KASAN
use-after-free splat on disconnect.

Reorder teardown to unregister the device before freeing its
private data.

Fixes: 54a4f0239f2e ("net: foo: add initial probe support")
Signed-off-by: Raghu Bharadwaj <you@example.org>

If you used any AI coding assistant while preparing the change, the current process asks you to record that with an Assisted-by: tag; failing to disclose it can hurt acceptance. Keep one logical change per commit. If the message starts to describe two unrelated things, split it into two patches.

Check the patch before you send it

Never send a patch you have not style-checked and built. Run the style checker on your commit; --strict turns on the stricter CHECK-level advice that maintainers often expect from new code:

raghu@techveda.org:~$ ./scripts/checkpatch.pl --strict --git HEAD
total: 0 errors, 0 warnings, 0 checks, 24 lines checked

checkpatch reports at three levels: ERROR for things very likely wrong, WARNING for things needing review, and CHECK for things needing thought. You should be able to justify every violation that remains. The checker is a guide, not a replacement for judgement, so do not make code worse just to silence it. Then confirm the tree still builds cleanly with your change applied; a patch that breaks the build will be rejected without a real review.

Generate the patch as a file. Using --base=auto records the base commit so reviewers and CI know exactly what your work applies to:

raghu@techveda.org:~$ git format-patch -1 --base=auto -o outgoing/
outgoing/0001-net-foo-avoid-use-after-free-on-probe-failure.patch

Your move → Read your own patch one more time as plain text in the outgoing/ file. The subject line becomes a permanent, searchable identifier for your change, so keep it under about 70 characters and make it describe what and why.

Send the patch to the right people

Find the correct recipients with the maintainer script. Pass it your patch file, not a source file:

raghu@techveda.org:~$ ./scripts/get_maintainer.pl outgoing/0001-net-foo-avoid-use-after-free-on-probe-failure.patch

Send the patch inline as plain text. Patches must not be sent as attachments, because reviewers need to quote your code line by line in their replies. The recommended tool is git send-email, which formats the subject prefix, sign-off, and separators correctly and is far less error-prone than a normal mail client. You can let the maintainer script fill the Cc list automatically:

raghu@techveda.org:~$ git send-email 
    --cc-cmd='./scripts/get_maintainer.pl --norolestats outgoing/0001-net-foo-avoid-use-after-free-on-probe-failure.patch' 
    outgoing/0001-net-foo-avoid-use-after-free-on-probe-failure.patch

Always Cc the subsystem list and the maintainers; linux-kernel@vger.kernel.org is the default catch-all list, but do not spam unrelated lists or people. If you would rather not manage these mechanics by hand, the b4 tool automates much of the format, check, and send flow.

Respond to review, which is what decides acceptance

Most first patches are not merged as sent. You will get review comments, and responding to them well is the part that actually gets your patch accepted. Reply to the comments, thank the reviewer, and use trimmed, interleaved replies rather than top-posting. When you send a new version, bump the version in the subject (the tooling produces [PATCH v2] for you) and add a short changelog below the --- separator explaining what changed since the previous version, so it does not become part of the permanent commit log.

Be patient. Reviewers are busy and you may wait two to three weeks for a response. Wait at least a week before pinging or resending, and longer during a merge window. If a reviewer offers a Reviewed-by: or Tested-by: tag, carry it forward on the next version unless the patch changed substantially. Persistence and politeness matter more than cleverness when getting a first patch merged.

Key takeaways

• Choose a small, real, single-purpose change and base it on the correct tree from the MAINTAINERS file.
• Commit with git commit -s so your Signed-off-by: certifies the work; write the message in imperative mood and add a Fixes: tag when you fix a known commit.
• Run scripts/checkpatch.pl --strict and confirm a clean build before you send anything.
• Route the patch with scripts/get_maintainer.pl and send it inline with git send-email; never attach it.
• Disclose AI assistance with an Assisted-by: tag, and treat review feedback as the main work, not an afterthought.

Further reading

• Submitting patches: the essential guide (kernel.org)
• Linux Kernel patch submission checklist (kernel.org)
• Linux kernel coding style (kernel.org)
• b4: tooling for preparing and sending patches
• Interactive git send-email tutorial