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.

The Linux kernel does not accept contributions through GitHub pull requests. All patches are submitted by email to mailing lists, reviewed publicly, and merged by subsystem maintainers who eventually send pull requests to Linus Torvalds. This page explains how that process works — from setting up your environment and writing code, to formatting your patch and sending it to the right list.

​
How the process works

Every change to the kernel goes through the following cycle:
  1. A developer writes a patch against the relevant subsystem tree.
  2. The patch is sent by email (plain text, inline) to the subsystem mailing list and the relevant maintainers.
  3. Maintainers and community members review the patch on the list.
  4. The developer addresses feedback and resends revised versions.
  5. The subsystem maintainer accepts the patch into their tree.
  6. At the end of the merge window, maintainers send pull requests to Linus, who merges changes into mainline.
Contributions are tracked through mailing list archives at lore.kernel.org. All review history is public.

​
Required tools

You need the following tools before you start:
  • git — the kernel uses git exclusively; patches are generated with git format-patch
  • git send-email — the recommended way to send patches; see Documentation/process/email-clients.rst for client configuration
  • scripts/checkpatch.pl — a Perl script inside the kernel tree that checks patches for style violations
  • scripts/get_maintainer.pl — finds the correct maintainers and mailing lists for any file in the tree

​
Submission workflow

1

Get the source

Clone the mainline kernel tree. Most subsystem maintainers want patches based on their own tree, but starting from mainline is correct for initial work:
git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
cd linux/
Check the MAINTAINERS file or the T: entry for the subsystem you are working on to find the subsystem tree. Clone that tree instead if you know which subsystem your change targets.
Use git log --oneline drivers/your/subsystem/ to understand recent activity and commit message conventions before writing your own.
2

Write and test your change

Make your changes in a dedicated branch:
git checkout -b my-fix origin/master
# ... edit files ...
git add -p
git commit -s
The -s flag adds your Signed-off-by: line, which is required for all kernel contributions. It certifies the Developer’s Certificate of Origin (DCO): you wrote the code, or have the right to submit it under the applicable open-source license.Each commit should represent a single logical change. If your work spans multiple concerns (for example, a bug fix and a cleanup), separate them into separate commits.Test your change before submitting. At minimum, verify the kernel builds without errors or new warnings with your change applied.
3

Write a good commit message

The commit message becomes the permanent changelog entry. Write it in imperative mood (“fix buffer overflow in foo_read”) and structure it as follows:
subsystem: concise summary of what and why (max 72 chars)

Describe the problem this patch solves. Include user-visible impact,
reproducer details, and any relevant error messages or stack traces.

Explain what the patch does technically in enough detail that a reviewer
unfamiliar with recent discussions can understand the reasoning.

Fixes: 54a4f0239f2e ("KVM: MMU: make kvm_mmu_zap_page() return the number of pages it actually freed")
Signed-off-by: Your Name <your@email.example>
Use Fixes: when your patch corrects a specific prior commit. Use Closes: with a URL to reference a public bug report. Use Link: to point to relevant mailing list discussions on lore.kernel.org.
4

Check coding style

The kernel follows strict coding style rules documented in Documentation/process/coding-style.rst. Run checkpatch.pl against your patch before sending:
git format-patch -1 --stdout | ./scripts/checkpatch.pl -
The checker reports at three levels: ERROR (likely wrong), WARNING (requires careful review), and CHECK (requires thought). Resolve all ERRORs. Address WARNINGs unless you have a clear reason not to.
Patches with obvious style violations are typically rejected without review. Running checkpatch.pl before sending saves everyone time.
5

Find the right maintainers and lists

Use get_maintainer.pl to identify who should receive your patch:
git format-patch -1 --stdout | ./scripts/get_maintainer.pl
This outputs the maintainers and mailing lists to CC. Always include linux-kernel@vger.kernel.org as a default list. For security-sensitive bugs, send to security@kernel.org instead of a public list.The MAINTAINERS file at the root of the tree lists every subsystem, its maintainers, and the associated mailing list. Look up the L: entry for the mailing list and the T: entry for the subsystem git tree.
6

Format and send the patch

Generate the patch file with git format-patch:
git format-patch --base=auto -o outgoing/ origin/master
For a single patch, send it directly. For a series of patches, add a cover letter:
git format-patch --base=auto --cover-letter -o outgoing/ origin/master
# edit outgoing/0000-cover-letter.patch to describe the series
Send using git send-email:
git send-email --to=subsystem@vger.kernel.org \
               --cc=maintainer@example.com \
               outgoing/*.patch
Patches must be sent inline as plain text. Do not send them as MIME attachments. Do not use HTML email. Configure your email client to avoid word-wrapping and whitespace mangling — see Documentation/process/email-clients.rst for client-specific settings.
An interactive tutorial for git send-email is available at git-send-email.io.
7

Respond to review feedback

Reviewers reply to your patch on the mailing list. Use interleaved (inline) replies — do not top-post. Address each comment and send a revised version with the version number incremented in the subject:
Subject: [PATCH v2] subsystem: fix buffer overflow in foo_read
Include a changelog below the --- separator in your cover letter or patch description explaining what changed between versions:
---
v2: addressed review comments from Jane Doe
  - removed unnecessary NULL check
  - simplified locking in the error path
v1: https://lore.kernel.org/your-original-patch-link
Add reviewers who provided feedback to the CC list of the next version. Be patient — reviewers are busy and may take two to three weeks to respond.

​
Key resources

lore.kernel.org

Searchable archive of all kernel mailing lists. Use it to find relevant prior patches, understand subsystem conventions, and link to discussions in your commit messages.

MAINTAINERS file

Lists every subsystem, its maintainers, mailing list, git tree, and relevant files. Always consult this before sending a patch.

Submitting patches guide

The authoritative upstream guide to the full patch submission process, including tag usage, patch format, and etiquette.

Kernel Newbies

Community resources, mentorship, and beginner-friendly tasks for new kernel developers.

​
Code of conduct

The Linux kernel project follows the Contributor Covenant Code of Conduct. All participants in kernel development — on mailing lists, in review discussions, and at events — are expected to treat each other with respect. The full text is in Documentation/process/code-of-conduct.rst.

​
Note on AI coding assistants

If you use an AI coding tool to help write kernel code, you must acknowledge this in your patch by adding an Assisted-by: tag: 
Assisted-by: ToolName:ModelVersion [optional-analysis-tools]
For example: Assisted-by: Claude:claude-3-opus coccinelle sparse Regardless of how the code was generated, only the human submitter may add the Signed-off-by: tag. The human is responsible for reviewing all AI-generated code, ensuring GPL-2.0 license compatibility, and certifying the Developer’s Certificate of Origin. See Documentation/process/coding-assistants.rst for the full requirements.

Build docs developers (and LLMs) love

Get started for freeTalk to us