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.

Submitting a patch to the Linux kernel is not simply a matter of attaching a diff to an email. The community has developed specific conventions for patch format, commit messages, sign-off lines, and sending method. Following them correctly significantly increases the chances that your work will be reviewed and accepted.

​
Before you start

Patches must be prepared against a specific version of the kernel. Use the mainline tree as your base: 
git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
Most subsystem maintainers want patches based on their own tree, not the mainline. Check the T: field in the MAINTAINERS file for the correct base tree, or ask the maintainer directly.
Before creating your first patch, make sure you have read Documentation/process/coding-style.rst and that scripts/checkpatch.pl reports no errors. Reviewers will request style fixes before reading the code.

​
Writing a good commit message

Each patch must have a clear, self-contained commit message. It should explain the problem, describe the solution, and give reviewers enough context to understand why the change is needed — even months or years later. The subject line format is: 
subsystem: brief imperative description of the change
For example: 
gpio: fix build on CONFIG_GPIO_SYSFS=n
ext2: improve scalability of bitmap searching
Write in the imperative mood: “fix the bug”, not “fixes the bug” or “I fixed the bug”. The body should describe the problem being solved, the approach taken, and any relevant performance data or trade-offs.
If you are referencing an earlier commit that introduced the bug, include both the 12-character SHA-1 prefix and the commit title:
Fixes: 54a4f0239f2e ("KVM: MMU: make kvm_mmu_zap_page() return the number of pages it actually freed")
Keep each patch focused on a single logical change. If your description is getting long, that is a signal to split the patch.

​
The Developer’s Certificate of Origin

Every patch must include a Signed-off-by: line. This certifies that you have the right to submit the code under the open-source license indicated in the file, in accordance with the Developer’s Certificate of Origin (DCO): 
Signed-off-by: Your Name <your@email.example.com>
By adding this line, you certify that the contribution was created by you, is based on prior work with a compatible license, or was provided to you by someone who certified the same. You are also acknowledging that the contribution is public and will be maintained indefinitely. Use git commit -s to add the sign-off automatically. For reverts, git revert -s adds it as well. Additional tags that may appear after the sign-off:
TagMeaning
Acked-by:A developer (often a maintainer) has reviewed and is satisfied with the patch
Reviewed-by:A technical review was carried out and the patch is found acceptable
Tested-by:The named person has tested the patch in some environment
Reported-by:Credits the person who discovered and reported the bug
Co-developed-by:The patch was created jointly; must be followed immediately by a Signed-off-by:
All tags except Cc:, Reported-by:, and Suggested-by: require explicit permission from the person named. Do not add Reviewed-by: or Acked-by: tags on someone else’s behalf without their approval.

​
Step-by-step submission workflow

1

Find the right maintainer

Run scripts/get_maintainer.pl against your patch file to identify the correct subsystem maintainer and mailing list:
./scripts/get_maintainer.pl mypatch.patch
Cross-check with the MAINTAINERS file. The M: field lists the maintainer email, L: lists the mailing list, and T: lists the subsystem tree.
2

Separate your changes into logical patches

Each patch should make one logical change. Bug fixes and feature additions for the same driver belong in separate patches. API changes and the new code that uses the API belong in separate patches. Every patch in the series must leave the kernel in a buildable, working state so that git bisect can function correctly.
3

Run checkpatch and fix style issues

./scripts/checkpatch.pl mypatch.patch
Address all ERROR and WARNING messages. Be prepared to justify any remaining CHECK messages.
4

Format patches with git format-patch

For a single patch:
git format-patch -1 HEAD
For a series of patches with a cover letter:
git format-patch --cover-letter --base=auto -o outgoing/ origin/master
The --base=auto flag embeds the base commit information, which helps automated CI tools and reviewers apply your series cleanly.
5

Write the cover letter (for patch series)

For anything more than a trivial single patch, write a cover letter (0000-cover-letter.patch) that explains the overall goal of the series, any testing done, and context that applies to all patches. The cover letter does not appear in the git log — make sure individual patch commit messages are also complete.
6

Send with git send-email

git send-email --to=maintainer@example.com \
               --cc=subsystem-list@vger.kernel.org \
               outgoing/*.patch
Patches must be sent as plain text inline in the email body, never as MIME attachments. git send-email handles this correctly. See the interactive tutorial at git-send-email.io if you are setting it up for the first time.

​
Patch format details

The canonical patch subject line for a series looks like: 
Subject: [PATCH 2/5] ext2: improve scalability of bitmap searching
Subject: [PATCH v2 01/27] x86: fix eflags tracking
For revised versions, increment the version tag (v2, v3) and add a changelog after the --- separator in each patch: 
Signed-off-by: Author <author@mail>
---
V2 -> V3: Removed redundant helper function
V1 -> V2: Cleaned up coding style and addressed review comments

v2: https://lore.kernel.org/bar
v1: https://lore.kernel.org/foo

path/to/file | 5 +++--
Everything after --- is stripped when the patch is applied and does not appear in the commit log.

​
Responding to review

Your patch will almost certainly receive review comments. You must respond to them — ignoring reviewers is the fastest way to ensure your patch is never merged.
Reply inline to the reviewer’s email. Explain what changes you made and thank them for their time. If you disagree with a comment, explain your reasoning politely. Add commenters to the Cc: list of your next revision so they see the updated version.
Expect 2–3 weeks for initial feedback. If you hear nothing, wait at least a week before resending. You can resend with RESEND in the subject only if the patch is unchanged:
[PATCH v1 RESEND] sub/sys: Condensed patch summary
If your patch fixes a significant bug in released kernels, add this to the sign-off area of the patch (not as a mail recipient):
Cc: stable@vger.kernel.org
The stable team will see it once your patch merges into the mainline.
Send patches fixing exploitable security bugs to security@kernel.org rather than public mailing lists. A short embargo may be arranged for severe issues to allow distributions time to prepare.

​
Common mistakes

Never attach patches as MIME attachments. Many email clients mangle them. Send plain text inline using git send-email.
Sending a networking patch to linux-kernel instead of netdev will result in a redirect and delay. Always use scripts/get_maintainer.pl and the MAINTAINERS file.
Top-posting is strongly discouraged in kernel discussions. Use interleaved (inline) replies. Quote only the portions of the previous message you are responding to.
Basing a patch on the wrong tree means it may not apply cleanly. Check the T: field in MAINTAINERS and use git format-patch --base=auto to include base commit information.

Build docs developers (and LLMs) love

Get started for freeTalk to us