Kernel Git, maintainers, stable, and upstream workflow

Before you start#

Review Git and source navigation, ext4 and journaling, and regression evidence. The source examples use upstream Linux v6.12, a historical teaching baseline, not a deployment or current-security recommendation. Project processes and active maintainers change: consult current authoritative project documentation when preparing real work.

Learning goals#

Read Git history without confusing names and objects, route a change using v6.12 maintainer metadata, distinguish stable from mainline and linux-next, and prepare reviewable evidence without sending or publishing anything.

Source walkthrough#

A Git blob stores file content; a tree maps names to blobs and subtrees; a commit points to a tree and parent commit or commits, with author, committer and message metadata. A branch is a movable name for a commit, not a copy of all its files. A remote is a configured location and a remote-tracking ref is a locally stored view updated by fetch. A tag names an object; an annotated tag is itself an object containing metadata and can carry a signature. Verify an annotated tag's signature against a trusted key and policy rather than assuming a tag name authenticates a download. A commit hash identifies content and history under Git's object model, but does not by itself establish who approved the change or that it is safe.

Mainline is the development tree into which changes are integrated. Subsystem maintainers develop and review changes in their trees and send pull requests during the release cycle; linux-next integrates many development trees for early integration testing. These trees can contain changes not yet in a release and can be rebased or replaced according to their maintainers' practices. Stable trees carry selected fixes for released kernels under stable rules; they are not interchangeable with a development branch. A historical tag such as v6.12 is useful for reproducible study but does not demonstrate that a deployed system has current security fixes. Stable support and current release status change over time, so consult current kernel.org release information for operational decisions rather than treating this snapshot as current.

Maintainer metadata and actual routing#

The v6.12 MAINTAINERS file lists sections with maintainers, lists, status, trees and path patterns. The ext4 section contains this exact short v6.12 excerpt; the inspected file has no file-level SPDX identifier or specific license notice; consult the repository licensing information rather than inferring one from this excerpt:

S:	Maintained
W:	http://ext4.wiki.kernel.org
Q:	http://patchwork.ozlabs.org/project/linux-ext4/list/
T:	git git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4.git
F:	Documentation/filesystems/ext4/
F:	fs/ext4/

The status line describes the section's maintenance status at this tag. The website, patch-tracking and tree lines are historical routing metadata; their current availability and role should be verified separately. The F: patterns cover matching paths, including fs/ext4/fsync.c. The full section also lists maintainers and the ext4 mailing list. A file can match multiple sections, and X: exclusions, regular-expression keywords, path specificity and tool options affect results. A pattern is a routing hint, not a grant of authority to send an email or a guarantee that the listed people currently maintain the code.

scripts/get_maintainer.pl parses sections and can use patch or file input as well as selected Git history. Its exclusion loop contains this exact v6.12 SPDX GPL-2.0 excerpt, copyright Joe Perches and contributors; surrounding loop and later matching are omitted:

		    if ($type eq 'X') {
			if (file_match_pattern($file, $value)) {
			    $exclude = 1;

The first condition identifies an exclusion entry; the next tests the file against that pattern; the assignment marks the section excluded for this match. The rest of the function handles the loop and applicable positive matches. The tool's Git options can add recent signers or use blame, while configuration and history available in a shallow checkout affect results. Review the full output, relevant source and recent discussion before proposing recipients. No email is sent by a read-only listing.

A real ext4 history route#

For one bounded example, the v6.12 source path fs/ext4/fsync.c implements ext4_sync_file, discussed in the end-to-end investigation. The pinned MAINTAINERS entry's F: fs/ext4/ pattern covers it. A GitHub API query for commits reachable from v6.12 affecting this path returned commit 95257987a6387f02970eda707e55a06cce734e18, titled “ext4: drop EXT4_MF_FS_ABORTED flag,” and eb8ab4443aec5ffe923a471b337568a8158cd32b, titled “ext4: make ext4_forced_shutdown() take struct super_block.” These are historical source references, not claims that the current maintainers approved a proposed patch or that either commit caused a particular regression.

Inspect the actual diff and its parent before interpreting why ext4_forced_shutdown changed. A commit list can include merges, and path history simplification can hide relevant context. git show reveals a commit's message and diff; git blame associates surviving lines with earlier changes but does not prove the blamed author introduced the underlying bug. A later fix can move code, alter semantics indirectly or revert an earlier change. Follow relevant callers and history across renames where appropriate, and read discussion or linked fixes before attributing intent.

A merge base is a best common ancestor of two histories, not necessarily the exact base used to prepare a patch series. Multiple merge bases can exist. Comparing a branch to a chosen base shows differences but does not establish that the branch contains every dependency required by a maintainer tree. A revert is a new commit that reverses selected changes; the original commit remains in history. Reverting can itself need adjustment when later code depends on the original change. git bisect narrows a reproducible good/bad transition under consistent classification, not proof that the first identified commit is the ultimate root cause.

Series construction and review#

A reviewable patch series states its base, problem, intended behavior and rationale. The reviewer should also know which tests were run, which configurations were unavailable, and whether a proposed fix changes a stable userspace contract. Record failures and skips alongside passes so the scope of the evidence remains visible. Each patch should be a coherent step that reviewers can understand and, where practical, build and test. Dependencies and ordering matter: a test added before a fix may intentionally fail in an intermediate revision, so explain the series structure and relevant testing. A good subject identifies the subsystem and concrete change; the body describes the trigger, causal mechanism and result. Include a precise Fixes: reference when applicable and supported by the project's process, not a guessed hash chosen only because blame pointed nearby.

A Signed-off-by line is a developer's certification under the Developer's Certificate of Origin (DCO) and the submission process. It is not a transfer of copyright, a statement that the signer owns all code, or a replacement for file licensing and authorship information. Preserve correct authorship and attribution. Review tags such as Reviewed-by and Tested-by represent specific people and actions; never invent them. The v6.12 submission guide defines the historical process and should be read alongside current maintainer guidance before any actual submission.

scripts/checkpatch.pl can flag many style and common patch issues. Its output is a review aid, not a proof of correctness, security, portability, proper locking or acceptability. A warning can require a justified exception; a clean result can still contain a use-after-free or broken ABI. Test the actual affected configurations and explain limitations. Reviewers need the change's ownership, lifetime and error paths, not merely a statement that formatting passed.

Stable fixes and security reports#

Stable selection has its own documented criteria and workflow. A fix that is correct in mainline may need a different backport because APIs, context or dependencies differ in an older tree. A mechanically clean cherry-pick is not proof of equivalent behavior; test the actual target tree and preserve provenance. Conversely, an old release number does not imply an unfixed issue if a vendor backported the fix. Inspect the deployed build and maintained update channel.

A security issue can require private coordinated reporting rather than a public patch, issue or mailing-list message. The historical security-bug process is a source reference, but current reporting instructions and contacts can change. Do not send exploit details, contact maintainers, upload a reproducer or publish a patch merely because this lesson describes the workflow. A responsible report states affected versions, configuration, impact, reproduction conditions and uncertainty without inventing a severity or exposing unrelated sensitive data.

Maintainers have limited review time and different subsystem conventions. A careful contributor reads the relevant MAINTAINERS section and subsystem documentation, examines existing tests and neighboring patches, answers questions and revises the series while preserving review history as appropriate. A local check or a maintainer name in a file is not upstream acceptance. Independent review can identify assumptions the author missed, particularly in concurrency, compatibility and failure cleanup.

Reading the ext4 change as evidence#

The two selected ext4 commits illustrate why a reviewer should inspect more than the newest line of blame. The earlier titled change adjusts the helper interface so the forced-shutdown check receives a superblock; the later titled change removes a filesystem flag. The commit titles suggest a relationship, but the actual diff, parent code and surrounding series are needed to determine precisely how the representation and callers changed. In the v6.12 ext4_sync_file path, a forced shutdown is checked before the normal data and journal synchronization sequence. A study note should quote the exact revision and state that this is a source observation, not an experiment that triggered a shutdown.

If a candidate regression appeared in an fsync error return, first ask whether both commits are ancestors of the reported build, whether a vendor backport changed their context, and whether the reproducer exercises that branch. A historical source change in the same file is not enough to establish cause. Compare the test and parent revision with the same configuration and backing device semantics. A merge commit can introduce a combination of independently correct changes; choosing a single line's blame without testing the merge and parents can hide that interaction.

Maintainer routing also has a scope. The ext4 section's path pattern points to subsystem expertise, while a change affecting generic VFS, block I/O or a security hook may match other sections. The tool can include historical contributors based on settings, and a shallow clone or patch touching generated files can produce incomplete or noisy output. The author should inspect path exclusions and the actual commit series, then check current routing if a future authorized submission is desired. Do not treat a copied historical email address as automatically current or as authorization to communicate.

What a reviewable series preserves#

A series is a sequence of states a reviewer must understand. The cover letter can explain a cross-subsystem motivation and ordering, while each commit explains its own invariant and test. Separate a mechanical refactor from a semantic fix when that makes the evidence clearer; avoid splitting a change so that intermediate commits violate required build or runtime assumptions without explanation. A reviewer can then examine the exact base, dependencies and resulting behavior instead of reconstructing an undocumented local history.

The DCO sign-off belongs to the actual person certifying the contribution under the documented terms. Authorship, co-authorship and review tags should accurately represent who did the work. A generated patch can contain code derived from several sources with different license notices; verify provenance rather than assuming one sign-off resolves ownership. A reviewer or maintainer may request changes, a different test, or a split series. Acknowledging and addressing that feedback is part of engineering evidence; it is not a ritual that automatically turns a patch into a safe release.

Practice#

Read-only history and routing

In a clean Linux checkout with the v6.12 tag and sufficient local history, run these commands without changing a branch, index or files:

git describe --tags --exact-match v6.12
git log --format='%h %ad %s' --date=short v6.12 -- fs/ext4/fsync.c | head -n 12
git show --stat --oneline 95257987a6387f02970eda707e55a06cce734e18
git blame v6.12 -- fs/ext4/fsync.c | head -n 12
./scripts/get_maintainer.pl --file fs/ext4/fsync.c

The tag command identifies the selected name; signature verification is a separate operation requiring trusted keys. A shallow clone can lack the historical commit or blame context, and get_maintainer.pl results can differ with options, configuration and available history. Do not fetch, send mail, commit or modify the user's repository for this exercise. Record exact commands and output, inspect the ext4 section and state whether the selected commit is actually an ancestor of the source being studied.

Source-only alternative: use the supplied v6.12 ext4 section and the two pinned historical commit links. Make a routing table with file, matching pattern, historical section status and one uncertainty about current ownership. Explain why a blame result would not by itself prove causation. Deliver the table or read-only command output; do not contact anyone.

Knowledge check#

1. How does an annotated tag differ from a branch name and a commit object?
2. What does an X: maintainer entry do in the cited matching loop?
3. Why is a blamed line not necessarily the root cause of a regression?
4. What does a DCO sign-off certify, and what does it not transfer?
5. Why can a clean stable backport still require independent testing?

Answers#

1. A branch is a movable reference, a commit records a tree and parents, and an annotated tag is a separate metadata object that can be signed. A name alone is not trusted verification.
2. When the file matches an exclusion pattern, the section is marked excluded for that match; later routing logic and other sections still matter.
3. Blame identifies the commit associated with surviving text under Git's algorithm, not necessarily the first incorrect design, later interaction or actual failure mechanism.
4. It certifies the contributor's statement under the DCO and submission process. It does not itself transfer copyright or prove correctness.
5. Older APIs, dependencies, configuration and surrounding code can differ even if the patch applies cleanly. Test the actual target and preserve provenance.

Checkpoint#

Submit the ext4 routing and history table, including the tag, two pinned commits, pattern/exclusion semantics and one uncertainty. Ready means no recipient, review tag or causal claim is invented and current practice is distinguished from the historical snapshot. Retry with the full source and history if blame is treated as proof. This is not certification.

Sources#

• MAINTAINERS v6.12
• get_maintainer.pl v6.12
• Submitting patches v6.12
• Stable kernel rules v6.12
• Bisecting a regression v6.12