Development workflow

The end-to-end path from a code change to a merged commit.

Branch off the right tree

For most subsystems, the patch should apply cleanly to either:

• The relevant subsystem's for-next branch (e.g. linux-mm/master, net-next/main, linux-block/for-next), or
• linux-next (the integration tree)

Working from master (Linus's tree) is fine for small fixes; for larger work, base on the subsystem tree.

git remote add net-next https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git
git fetch net-next
git checkout -b my-feature net-next/main

Make focused commits

• One logical change per commit.
• Subject line: subsystem: short summary. ~50 characters max.
• Body: explain why, wrap at 72 columns, plain text. Include problem statement, what you changed, and how you tested.
• Add a Signed-off-by: trailer.

Common trailers (Documentation/process/submitting-patches.rst § Trailers):

• Signed-off-by: — your DCO sign-off (required).
• Reviewed-by: — added by reviewers when they're satisfied.
• Tested-by: — added by people who tested the patch.
• Reported-by: — credit the bug reporter.
• Suggested-by: — credit a suggestion source.
• Acked-by: — a maintainer's acknowledgement, often without full review.
• Co-developed-by: paired with another Signed-off-by: when there are multiple authors.
• Fixes: <12-char-sha> ("subject of broken commit") — for bug fixes targeting a specific commit.
• Cc: stable@vger.kernel.org — to be picked up by the stable trees.

Format the series

git format-patch -<N> --subject-prefix="PATCH" -o /tmp/series origin/master

For series of more than one patch, add a cover letter:

git format-patch -<N> --cover-letter -o /tmp/series origin/master

Edit the generated 0000-cover-letter.patch to describe the series, motivation, and a changelog from previous versions if this is a v2 / v3 / etc.

Run checkpatch

./scripts/checkpatch.pl --strict /tmp/series/*.patch

Fix the errors. Most warnings should be addressed unless there's a good reason. Some patterns checkpatch flags are subjective (line length when it would harm readability to wrap, for instance), and reviewers will allow them in those cases.

Identify the recipients

./scripts/get_maintainer.pl /tmp/series/0001-*.patch

This prints the maintainers, reviewers, mailing lists, and pertinent open lists (linux-kernel@vger.kernel.org is almost always on the Cc).

Send the patches

git send-email \
  --to "Maintainer Name <maintainer@example.org>" \
  --cc "linux-foo@vger.kernel.org" \
  --cc "linux-kernel@vger.kernel.org" \
  /tmp/series/*.patch

Configuration: see Documentation/process/email-clients.rst. Set up git send-email once with your SMTP server and from address.

Respond to review

• Reply inline (no top-posting). Keep relevant context, trim the rest.
• If you change code in response, post a v2 (and label it). Don't repost the same patch under a new subject.
• Keep the changelog at the bottom of the cover letter:

  Changes in v3:
  - Address Foo's review (rename helper)
  - Fix typo in commit message
  Changes in v2:
  - Drop unused argument from helper

How the patch becomes "merged"

When the maintainer is happy, they apply the patch to their subsystem tree. From there it flows into linux-next and ultimately, during the next merge window, into Linus's tree. The maintainer adds a Signed-off-by: of their own when they apply it. You do not need to do anything else; you will see the commit appear when the subsystem tree is updated, and eventually with a Linus Torvalds Signed-off-by: once it lands in mainline.

Stable backports

To request that a fix be backported to stable kernels, add Cc: stable@vger.kernel.org to the commit message (or note it in the cover letter). The stable maintainers (Greg Kroah-Hartman et al.) pick from mainline; see Documentation/process/stable-kernel-rules.rst.

Useful day-to-day commands

# Cross-compile build smoke test
make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- defconfig
make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- -j$(nproc)

# Re-run sparse on changed files
make C=2

# Check for new warnings vs. baseline
make W=1 -j$(nproc) 2>&1 | tee build.log

# Find recent commits that touched a file
git log --oneline -20 -- mm/slub.c

Related pages

• Patterns and conventions — coding style and idioms expected by reviewers.
• Testing — what to run before sending patches.
• Tooling — checkpatch, sparse, smatch, coccinelle.