Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/deelerdev/linux/llms.txt

Use this file to discover all available pages before exploring further.

Getting a patch accepted into the Linux kernel is a well-defined process, but one that takes practice to get right. The guidelines below are not arbitrary — they exist to help reviewers read, understand, and test your change as efficiently as possible. Following them closely increases your odds of acceptance significantly.
This guide assumes you are using git to prepare your patches. If you are not yet familiar with git, learning it before submitting patches will save considerable time.

​
The patch submission workflow

1

Obtain the right source tree

Start by cloning the mainline kernel tree, or — better — the subsystem tree where your change belongs. Most subsystem maintainers want patches prepared against their own tree rather than the mainline. Look for the T: entry in the MAINTAINERS file to find the correct tree.
git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
To find the subsystem tree, check the MAINTAINERS file or ask the maintainer directly.
2

Make one logical change per patch

Separate each logical change into its own patch. If your work includes both a bug fix and a performance improvement, those should be two separate patches. Each patch must be justifiable on its own merits and must leave the kernel buildable and functional after it is applied.If your patch series is large, post no more than around 15 patches at a time and wait for review before sending more.
3

Write a clear commit message

Your commit message is copied directly into the git changelog and becomes a permanent public record. Write it in the imperative mood (“make xyzzy do frotz”, not “I changed xyzzy”). The subject line follows this canonical format:
Subject: [PATCH 001/123] subsystem: summary phrase
The summary phrase must be no more than 70–75 characters. It must describe both what the patch changes and why it is necessary. The body should explain the problem, the solution, and any trade-offs — in enough detail that someone reading it two years from now will understand the reasoning.If your patch fixes a bug found via git bisect, include a Fixes: tag:
Fixes: 54a4f0239f2e ("KVM: MMU: make kvm_mmu_zap_page() return the number of pages it actually freed")
If it closes a public bug report, include a Closes: tag:
Closes: https://example.com/issues/1234
4

Add your Signed-off-by line

Every patch must carry a Signed-off-by: trailer. This is your certification under the Developer’s Certificate of Origin that you have the right to submit the code. Use git commit -s to add it automatically:
git commit -s
The resulting line looks like:
Signed-off-by: Your Name <you@example.com>
Do not submit patches without a valid Signed-off-by. Anonymous contributions are not accepted.
5

Generate patches with git format-patch

Convert your commits to patch files. Use --base=auto so reviewers and CI systems know the exact commit your work applies to:
git checkout -t -b my-fix master
# ... make your changes and commit ...
git format-patch --base=auto --cover-letter -o outgoing/ master
For a single patch, omit --cover-letter. For a series, the cover letter (0000-cover-letter.patch) gives reviewers an overview of the series as a whole.
6

Check your patch with checkpatch.pl

Run the kernel’s style checker against each generated patch file before sending anything:
scripts/checkpatch.pl outgoing/*.patch
The checker reports at three severity levels:
  • ERROR — very likely wrong; must be fixed
  • WARNING — requires careful review
  • CHECK — requires thought
You should be able to justify any violation that remains. Sending patches with avoidable style errors wastes reviewer time and may result in the patch being ignored without review.
7

Find the right recipients with get_maintainer.pl

Pass your patch files to scripts/get_maintainer.pl to get the list of maintainers and mailing lists that should receive your change:
scripts/get_maintainer.pl outgoing/*.patch
The output lists maintainers, reviewers, and the mailing lists from the MAINTAINERS file and the git log for the affected files. Always copy both the relevant subsystem maintainer and the subsystem mailing list.For patches fixing severe security bugs, send to security@kernel.org instead of a public list.
8

Send with git send-email

The strongly recommended way to submit patches is git send-email. It sends patches as inline plain text, which is required — do not attach patches as MIME attachments.
git send-email --to=maintainer@example.com \
               --cc=subsystem-list@vger.kernel.org \
               outgoing/*.patch
An interactive tutorial is available at git-send-email.io. For email client configuration tips that prevent your mailer from mangling patches, see Documentation/process/email-clients.rst.
9

Respond to review comments

After sending your patch, be patient — expect a response within two to three weeks. When you receive review comments, respond to every one, even if only to explain why you disagree. Ignoring reviewers is the fastest way to ensure your future patches are also ignored.When you send a revised version, add a version descriptor to the subject (v2, v3) and include a patch changelog after the --- separator explaining what changed:
Signed-off-by: Your Name <you@example.com>
---
v2: Removed redundant helper function per review feedback
v1: https://lore.kernel.org/...

path/to/file | 5 +++--
Add the reviewers who commented to the Cc: list of your revised series.

​
Patch tags reference

Tags appear in the commit message trailer area and document the patch’s history and review status.
Required on every patch. Certifies that the signer wrote the code or has the right to submit it under the open-source license indicated in the file. The last Signed-off-by: must be that of the person submitting the patch.
Added by a maintainer or domain expert to indicate they have reviewed the patch and find it acceptable, even if they did not co-develop it. Less formal than Reviewed-by:.
A formal statement that the reviewer has carried out a technical review, communicated any concerns back to the author, and believes the patch is appropriate for inclusion. Increases the likelihood of acceptance when it comes from a recognized expert.
Confirms that the patch was successfully tested in some environment. Helps maintainers understand the testing coverage.
Credits the person who found and reported the bug. Must be followed by a Closes: or Link: tag pointing to the public report. Can be added without explicit permission if the person reported the issue publicly.
Attributes co-authorship when multiple developers worked on a single patch. Each Co-developed-by: must be immediately followed by the co-author’s Signed-off-by:.
Identifies the commit that introduced the bug being fixed. Include at least the first 12 characters of the SHA-1 and the oneline summary. Do not wrap this tag across multiple lines.

​
Common mistakes to avoid

Do not use AI coding assistants without disclosure. If you used any automated coding tool to help write your patch, you must add an Assisted-by: tag. Failing to disclose this may prevent your patch from being accepted. See Documentation/process/coding-assistants.rst for the full requirements.
  • Sending to the wrong list. Use scripts/get_maintainer.pl every time. Do not spam linux-kernel with subsystem-specific patches.
  • Top-posting in email replies. Place your response inline below the quoted text you are addressing.
  • Attaching patches as MIME attachments. Send patches inline using git send-email.
  • Submitting without Signed-off-by. Every patch must be signed off.
  • Combining unrelated changes in one patch. Each patch must represent one logical change.
  • Sending patches that do not apply cleanly. Keep your branch rebased against the target tree before sending.
  • Resending too soon. Wait at least one week before resending. During busy periods like merge windows, wait longer. When resending an unmodified patch, add RESEND to the subject.

Build docs developers (and LLMs) love

Get started for freeTalk to us