How to contribute

The Linux kernel does not accept GitHub pull requests. The torvalds/linux repository on GitHub is a mirror; the canonical tree is on git.kernel.org, and the canonical patch flow is email to mailing lists. This page describes the model. The authoritative source is Documentation/process/.

If you have read GitHub-style "fork, push, PR" guides for other projects, almost none of that applies here. Read this page first.

Mental model

graph LR
    DEV[Developer] -->|"git format-patch"| PATCH[Patch series]
    PATCH -->|"git send-email"| LIST[Subsystem list + maintainer]
    LIST -->|review, Reviewed-by, Tested-by| MAINT[Maintainer]
    MAINT -->|applies to subsystem tree| SUBTREE[linux-foo.git]
    SUBTREE -->|"pull request to Linus during merge window"| TORVALDS[Linus' tree]
    TORVALDS -->|tagged releases| STABLE[Stable trees]

There are hundreds of subsystem trees. Each subsystem tree feeds into Linus's tree during the two-week merge window that opens immediately after each release. After the merge window, 6–8 weekly -rc releases stabilize the tree. Then a new release is tagged and the cycle repeats.

The minimum viable workflow

1. Find the subsystem. Run scripts/get_maintainer.pl against the file you are touching:

   ./scripts/get_maintainer.pl path/to/file.c

   It returns the maintainer(s) and the relevant mailing list. Cc all of them.
2. Read the in-tree docs. Documentation/process/submitting-patches.rst is the canonical reference. Documentation/process/coding-style.rst is required reading.
3. Make focused, well-described changes. One change per patch. The commit message describes why. The first line is a short summary prefixed by subsystem (e.g. mm/slub: fix accounting on cgroup migration).
4. Run scripts/checkpatch.pl on each patch. Fix every error and most warnings. This is a hard gate in many subsystems.
5. Add Signed-off-by: on every patch. This is your assertion of the Developer Certificate of Origin (Documentation/process/submitting-patches.rst § DCO).
6. Send by email with git send-email. Inline patch (no attachments). Plain text only. No HTML.
7. Iterate. Reviewers reply with comments. Revise the series, post a v2/v3 with a changelog at the bottom of the cover letter.
8. The maintainer applies it to their tree when they are satisfied. You do not merge it yourself.

Sub-pages

• Development workflow — branches, git format-patch, git send-email, cover letters, versions.
• Testing — kselftest, KUnit, lockdep, KASAN, syzkaller.
• Debugging — printk, ftrace, kgdb, dmesg, common errors.
• Patterns and conventions — coding style, error handling, locking conventions.
• Tooling — checkpatch, sparse, smatch, coccinelle, get_maintainer, dt-validate.

What "merging" means here

Every contribution goes through some maintainer's tree first. Even Linus's tree itself is the merging of maintainer trees during the merge window. There is no equivalent of a single "main" branch that everyone pushes to.

If your patch sits in a subsystem tree (often called linux-<area>.git, e.g. linux-mm, linux-fs, linux-block, net-next), it will appear in the next merge window. Until that point, it lives in linux-next (an aggregator tree that is rebuilt nightly from many subsystem trees). linux-next is what catches cross-subsystem build breakages.

Code of Conduct

The kernel has an enforced Code of Conduct (Documentation/process/code-of-conduct.rst). The community has visibly improved its review tone over the last several years; abusive review is no longer tolerated.

License

All contributions are GPL-2.0-only by default. Some files may also be available under additional licenses (e.g. dual MIT/GPL); check the SPDX-License-Identifier line on the file you are touching.

When you are stuck

• The mailing list archive is the documentation. lore.kernel.org indexes every list and is searchable.
• #kernelnewbies on irc.oftc.net is a low-pressure place to ask procedural questions.
• MAINTAINERS tells you not just who, but which list. Read the section header for the subsystem you are touching.