Contributing to the Linux kernel

The Linux kernel is developed through email-based patch submission. There are no pull requests, no web-based code review UI, and no bot-driven CI gates standing between you and a maintainer. Patches are sent as plain-text emails to subsystem mailing lists, where maintainers and other developers review them publicly. This guide walks through the end-to-end process.

This guide covers contributing to the upstream mainline kernel. Individual distributions may have additional requirements for packaging or stable-backport patches.

Before you begin

Code of Conduct

The Linux kernel project adopts the Contributor Covenant Code of Conduct. The community expects contributors and maintainers alike to:

Use welcoming and inclusive language
Respect differing viewpoints and experience levels
Accept constructive criticism gracefully
Focus on what is best for the community

Unacceptable behavior—including personal attacks, public or private harassment, and publishing private information without consent—may be reported to the Code of Conduct Committee at [email protected].

Developer Certificate of Origin

Every patch submitted to the kernel must carry a Signed-off-by: trailer. By adding this line you certify, under the Developer’s Certificate of Origin (DCO) version 1.1, that:

(a) The contribution was created in whole or in part by you and you have the right to submit it under the indicated open-source license; or
(b) The contribution is based on prior work covered by an appropriate open-source license and you have the right to submit modifications under the same license; or
(c) A person who certified (a), (b), or (c) provided the contribution directly to you and you have not modified it.
(d) You understand the contribution and the sign-off are public and maintained indefinitely.

Add the sign-off to every commit with:

git commit -s

This appends a line of the form:

Signed-off-by: Jane Developer <[email protected]>

Anonymous contributions are not accepted. The name and email in the Signed-off-by: line must match a real identity.

Finding something to work on

Fix a bug you have encountered

The most direct path into the kernel is fixing a bug that affects you. Reproduce it on the latest mainline kernel first—your bug may already be fixed. Check the mailing list archives at lore.kernel.org and bugzilla.kernel.org for existing reports.

Kernel Janitors / staging tree

The drivers/staging/ subtree contains drivers that are functional but do not yet meet kernel quality standards. The TODO file in each staging driver lists outstanding issues. Cleaning up checkpatch.pl warnings, fixing sparse errors, or improving documentation are well-understood starting tasks that maintainers welcome from new contributors.

KernelNewbies

KernelNewbies maintains a list of tasks labelled as suitable for beginners, along with a wiki documenting kernel internals and the contribution process. The #kernelnewbies IRC channel on irc.oftc.net is a helpful place to ask questions.

Documentation improvements

The Documentation/ tree is large, actively maintained, and always accepting improvements: correcting inaccuracies, converting RST markup, adding missing parameters, or writing new guides. The [email protected] mailing list handles documentation patches.

Work on a specific subsystem

Browse the MAINTAINERS file or the subsystem mailing list archives to find areas that interest you. Reading recent patch threads gives you a feel for what a maintainer expects and the quality of discussion in that area.

Coding style

The kernel has a well-defined coding style described in Documentation/process/coding-style.rst. Deviations cause patches to be returned for rework. Key rules:

Indentation and line length

Indent with tabs, where one tab equals 8 characters. Never use spaces for indentation.
Keep lines to a maximum of 80 columns. Longer lines are acceptable only when breaking them would significantly reduce readability.

/* Correct: tab indentation, opening brace on same line for control flow */
if (condition) {
	do_something();
	do_something_else();
}

/* Correct: function definition has opening brace on its own line */
int frobnicate(int x)
{
	return x * 2;
}

Braces and spacing

Opening braces for control-flow statements (if, for, while, switch) go on the same line.
Opening braces for function definitions go on the next line.
Do not add braces when a single statement suffices, unless one branch of an if/else pair requires them.
Use one space after keywords (if, for, while, switch, case). No space after sizeof, typeof, or alignof.
No spaces inside parenthesized expressions.
Place the * adjacent to the variable name in pointer declarations, not the type:

char *buf;
unsigned long long memparse(char *ptr, char **retptr);

Naming

Use lowercase with underscores (snake_case) for functions, variables, and macros.
Avoid encoding type information in names (no Hungarian notation).
Local variable names should be short and descriptive. Global symbols must be unambiguous.

Checking your patch

Run scripts/checkpatch.pl against your patch before sending it:

scripts/checkpatch.pl 0001-my-fix.patch

The checker reports at three levels — ERROR (very likely wrong), WARNING (needs careful review), and CHECK (requires thought). You should be able to justify every remaining violation. The checker is a guide, not a replacement for human judgment.

Preparing patches

One logical change per patch

Each patch must represent exactly one logical change. If you are both fixing a bug and cleaning up related code, use two separate patches. If a change spans many files, it may still belong in one patch as long as it constitutes a single logical unit. Series that interleave unrelated changes are routinely rejected. When building a series, ensure the kernel builds and runs correctly after each individual patch. Reviewers use git bisect to track regressions, and a series that introduces a broken intermediate state blocks that workflow.

Write a good commit message

The commit message is permanent: it becomes part of the git log that developers read for years. Structure it as:

subsystem: brief imperative summary (max 70–75 characters)

Describe the problem being solved. Explain user-visible impact, reproduce
steps, and any relevant context. Quantify performance improvements with
numbers. Write as if the reader has forgotten all context from the mailing
list discussion.

References to other commits should include the first 12 characters of the
SHA-1 and the one-line summary:

  Fixes: 54a4f0239f2e ("KVM: MMU: make kvm_mmu_zap_page() return the
         number of pages it actually freed")

Link: https://lore.kernel.org/some-list/message-id@host/
Closes: https://bugzilla.kernel.org/show_bug.cgi?id=12345
Signed-off-by: Jane Developer <[email protected]>

Write the summary in imperative mood: “fix null dereference in nfs_read” not “fixed” or “fixes”.

Generate patches with git format-patch

# Single patch
git format-patch -1 HEAD

# Patch series (last 3 commits) with a cover letter
git format-patch --cover-letter -3 HEAD -o outgoing/

# Include base tree information for automated CI
git format-patch --base=auto --cover-letter -o outgoing/ master

git format-patch produces numbered .patch files (e.g., 0001-fix-foo.patch) that git am can apply cleanly. The --base flag embeds the base commit hash so CI tools can reproduce the exact tree you tested against.

Submitting patches

Find the right maintainers and lists

Use scripts/get_maintainer.pl to determine which maintainers and mailing lists should receive your patch:

scripts/get_maintainer.pl 0001-my-fix.patch

The script reads the MAINTAINERS file and the git history of the files touched by your patch, and prints a list of names and email addresses with role annotations (maintainer, reviewer, list, etc.). Add every address it reports. [email protected] is the catch-all list and should be included by default, but many subsystems have their own primary list—prefer the subsystem list for the initial discussion.

Send with git send-email

Patches must be sent as plain-text inline email. Do not attach patches as files. Do not use HTML email. The standard tool is git send-email:

# Send a single patch
git send-email \
  --to="[email protected]" \
  --cc="[email protected]" \
  --cc="[email protected]" \
  0001-my-fix.patch

# Send a series (cover letter first)
git send-email \
  --to="[email protected]" \
  --cc="[email protected]" \
  outgoing/

Configure git send-email once to use your mail server. See Documentation/process/email-clients.rst for per-client instructions. A useful interactive tutorial for configuring git send-email is available at git-send-email.io.

Patch subject line format

The canonical subject format is:

[PATCH] subsystem: brief summary phrase
[PATCH v2 2/5] driver/foo: fix null check on bar allocation

[PATCH] is added automatically by git send-email.
Include a version tag (v2, v3) when resubmitting after review feedback.
For a series of N patches, number them 1/N, 2/N, … so reviewers know the full scope.
The subsystem prefix identifies the area being changed (e.g., net:, mm:, x86:, drm/i915:).

Patch tags reference

Tag	Meaning
`Signed-off-by:`	Author or handler certifies the DCO. Required on every patch.
`Reviewed-by:`	Reviewer has technically reviewed and found the patch acceptable.
`Acked-by:`	Stakeholder acknowledges and accepts the change.
`Tested-by:`	Named person has successfully tested the patch.
`Reported-by:`	Credits the person who reported the bug being fixed.
`Suggested-by:`	Credits the person who suggested the approach.
`Fixes:`	Identifies the commit that introduced the bug being fixed.
`Closes:`	URL to the bug report or mailing list thread being resolved.
`Link:`	URL to relevant background discussion.
`Co-developed-by:`	Credits a co-author; must be immediately followed by their `Signed-off-by:`.
`Cc: [email protected]`	Requests backport to stable kernels (in sign-off area, not email recipient).

All tags except Cc:, Reported-by:, and Suggested-by: require explicit permission from the named person before you add them.

The review process

Wait for feedback

After sending, allow at least one week before following up—longer during the merge window (the two-week period after each -rc1 when maintainers are busy pulling feature trees). You should normally receive a response within 2–3 weeks if the patch was sent to the correct lists.

Respond to review comments

Reply to reviewer emails inline (interleaved), quoting only the relevant section. Address each concern explicitly. Thank reviewers for their time—code review is laborious.If a comment does not lead to a code change, explain why in your reply. The reasoning is valuable context for future readers of the mailing list archives.

Submit a revised version

When submitting a revised patch, increment the version tag (v2, v3, …) and add a changelog below the --- separator line describing what changed between versions:

Signed-off-by: Jane Developer <[email protected]>
---
v3 -> v4: Addressed comment from Alice: rewrote locking section
v2 -> v3: Dropped unnecessary helper, fixed whitespace
v1 -> v2: Used IS_ERR() instead of explicit NULL check

v3: https://lore.kernel.org/some-list/v3-message-id@host/
v2: https://lore.kernel.org/some-list/v2-message-id@host/

CC all reviewers who commented on earlier versions so they can follow the revision.

Patch lands in a subsystem tree

Once a maintainer is satisfied, they apply the patch to their subsystem tree and it queues for the next merge window. You can track its progress on patchwork or by watching the subsystem tree on kernel.org.

Patch merges to mainline

During the merge window, subsystem maintainers send pull requests to Linus Torvalds. Your patch becomes part of mainline and will ship in the next kernel release.

Mailing lists and community resources

lore.kernel.org

Searchable archive of all kernel mailing lists. Use it to find existing discussions, check patch status, and construct Link: tags using the Message-ID of relevant threads.

patchwork.kernel.org

Tracks the state of patches sent to kernel mailing lists. Maintainers use it to manage their queues; contributors can check whether their patch has been picked up.

bugzilla.kernel.org

The official kernel bug tracker. Useful for finding reproducible bugs to fix and for filing new ones when a mailing list report is not appropriate.

KernelNewbies

Documentation, task lists, and a community (IRC: #kernelnewbies on irc.oftc.net) aimed at people getting started with kernel development.

b4 tooling

b4 automates many patch workflow tasks: retrieving patches from lore, checking dependencies, running checkpatch, and formatting and sending mail.

Security issues

Patches fixing exploitable security vulnerabilities should be sent to [email protected] rather than a public mailing list, to allow coordinated disclosure.

Key mailing lists

List	Purpose
`[email protected]`	General kernel development; catch-all for patches without a more specific list.
`[email protected]`	Documentation patches and doc tooling.
`[email protected]`	Networking core and drivers.
`[email protected]`	Memory management subsystem.
`[email protected]`	Filesystem and VFS development.
`[email protected]`	Stable kernel patch submissions and discussion.
`[email protected]`	Private channel for security vulnerability reports.

Get Started

Kernel Internals

Development Guide

Administration

Driver Development

Contributing to the Linux kernel

Before you begin

Code of Conduct

Developer Certificate of Origin

Finding something to work on

Coding style

Indentation and line length

Braces and spacing

Naming

Checking your patch

Preparing patches

One logical change per patch

Write a good commit message

Generate patches with git format-patch

Submitting patches

Find the right maintainers and lists

Send with git send-email

Patch subject line format

Patch tags reference

The review process

Mailing lists and community resources

lore.kernel.org

patchwork.kernel.org

bugzilla.kernel.org

KernelNewbies

b4 tooling

Security issues

Key mailing lists

Build docs developers (and LLMs) love

Get Started

Kernel Internals

Development Guide

Administration

Driver Development

​Before you begin

​Code of Conduct

​Developer Certificate of Origin

​Finding something to work on

​Coding style

​Indentation and line length

​Braces and spacing

​Naming

​Checking your patch

​Preparing patches

​One logical change per patch

​Write a good commit message

​Generate patches with git format-patch

​Submitting patches

​Find the right maintainers and lists

​Send with git send-email

​Patch subject line format

​Patch tags reference

​The review process

​Mailing lists and community resources

lore.kernel.org

patchwork.kernel.org

bugzilla.kernel.org

KernelNewbies

b4 tooling

Security issues

​Key mailing lists

Build docs developers (and LLMs) love

Before you begin

Code of Conduct

Developer Certificate of Origin

Finding something to work on

Coding style

Indentation and line length

Braces and spacing

Naming

Checking your patch

Preparing patches

One logical change per patch

Write a good commit message

Generate patches with git format-patch

Submitting patches

Find the right maintainers and lists

Send with git send-email

Patch subject line format

Patch tags reference

The review process

Mailing lists and community resources

Key mailing lists