gregkh/linux and the mechanics of the Linux kernel stable tree

A GitHub mirror of the stable tree, with binaries kept elsewhere

gregkh/linux is a GitHub mirror of the Linux kernel stable tree, and the repository description says so in four words. The default branch is master, the primary language is C, and the homepage points back to the canonical git repository at git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git, which tells you both where the GitHub copy comes from and which tree it tracks. There is no packaging here, no wrapper script and no installer. What you get is the kernel source tree itself: top-level entries include arch/, block/, drivers/, fs/, kernel/, mm/, net/, rust/, tools/ and virt/, sitting next to Makefile, Kconfig, Kbuild, MAINTAINERS, COPYING, a LICENSES/ directory and a Documentation/ tree that carries much of the project's substance. The topics are kernel and linux, and the repository has no GitHub releases, so nothing in this repository behaves like a distribution channel.

The top-level Makefile names a 7.3.0 tree called Baby Opossum Posse

The version fields sit at the top of the Makefile, and they are the quickest way to know what you cloned. Three integers and two strings give the tree's identity before a single object file is produced. The SPDX identifier on the same file shows how licensing travels with the code itself rather than in a separate document.

VERSION = 7
PATCHLEVEL = 3
SUBLEVEL = 0
EXTRAVERSION =
NAME = Baby Opossum Posse

The build under those fields is recursive. The file explains that sub-Makefiles should only ever modify files in their own directory, and where a dependency forces a call into another directory, a sub make is invoked first so that the built-in.a targets are known to be current before linking proceeds. Cases with global effects are pulled out ahead of the recursive descent and listed explicitly as the prepare rule. The default target when none is given on the command line is __all, and the file notes that a list of typical targets can be printed by running the help target.

The build stops before compilation when GNU Make is too old

One check in the Makefile runs before any work happens, and it aborts the invocation outright. A second guard rejects targets whose names begin with a double underscore, which are reserved for internal use. Both guards are worth reading before your first build, because they explain the shape of the toolchain expectations behind the tree.

	$(error GNU Make >= 4.0 is required. Your Make version is $(MAKE_VERSION))
	$(error targets prefixed with '__' are only for internal use)

This is also where the mirror's main limitation sits, and it is a structural one rather than a quality one. A source mirror gives you source, not a running system. There are no binary packages, no installer, no release artifacts and no rollback path documented in the README excerpt, and the tree has no GitHub releases to fall back on. The build also assumes more than the Make version: the README routes readers to the changes document for building requirements, which is where compiler and toolchain expectations are stated.

The README is a documentation index rather than an install guide

There are no install steps to copy out of this repository, so a first use means cloning, building from source and reading the documentation set. The README says the latest kernel lives at kernel.org, and that building is covered by Documentation/admin-guide/quickly-build-trimmed-linux.rst. Build requirements are described in Documentation/process/changes.rst. Documentation can be built with the htmldocs target, or read online at the kernel.org documentation site, which matters for readers who only want to look up a subsystem rather than compile anything.

The README also sorts readers by role, and the split is useful. New kernel developers are pointed at the coding style guide, the build system index under Documentation/kbuild, and the kernel hacking guide. System administrators get kernel parameters, sysctl tuning and tracing. The MAINTAINERS file lists subsystem maintainers and mailing lists, and the communication section points to the lore.kernel.org mailing list archives, the kernelnewbies IRC channel on irc.oftc.net and bugzilla.kernel.org for bug tracking.

AI tooling is handed its own contribution rules before it patches anything

One section of the README addresses automated coding tools directly, and it is unusual enough to be worth quoting. It instructs that if you are an LLM or AI powered coding assistant, you must read and follow the AI coding assistants documentation before contributing to the kernel, and it points to Documentation/process/coding-assistants.rst. The README states that this document sets out requirements about licensing, attribution and the Developer Certificate of Origin that all AI tools must comply with.

Practically, that changes the workflow for anyone using an assistant to draft a patch. The Developer Certificate of Origin is not a formality you can skip, because the document treats it as a requirement for every contribution path, automated or not. Attribution rules also intersect with the licensing model described in the next section, since the tree carries license identifiers at the file level.

Backport and maintenance rules sit beside the source, not in a wiki

The maintenance audience is served by a dedicated set of documents rather than by prose advice. Stable Kernel Rules defines how stable releases are governed, the Backporting Guide covers moving fixes onto released kernels, and Applying Patches handles the mechanics. Maintainer-oriented files sit in the maintainer directory: a maintainer entry profile, a Git configuration guide, and documents on pull requests, modifying patches, rebasing and merging. Security work has its own chain, including Documentation/process/cve.rst for CVE procedures, a document on embargoed hardware issues, and a separate guide to reporting vulnerabilities.

That is the real difference between this tree and a packaged kernel from a distribution. A distribution hands you a prebuilt artifact and keeps its own version policy, its own packaging and its own module signing setup. Building from this tree hands you the source of a stable kernel and the rulebook that governs it, but the packaging, signing and integration work is yours. Distributors are pointed at ABI documentation under Documentation/ABI, the Kconfig reference, the module signing guide and the tainted kernels document, which is an honest admission that the tree stops where a distribution's job begins.

Licensing travels per file, and the tree was pushed on 2026-10-19

The repository carries SPDX identifiers directly in source files, and the top-level LICENSES/ directory holds the license texts the tree refers to. The README points readers to the COPYING file for the license itself and describes the license as a custom arrangement that GitHub cannot classify, so the classification shown on the repository page is not the whole story. Anyone assessing reuse terms has to read COPYING and the per-file identifiers rather than relying on a badge, and this is a note about where the terms are recorded, not legal advice.

On maintenance, the repository is not archived and the last push was on 2026-10-21, which is a recent state for a tree of this size. The absence of GitHub releases is deliberate rather than a gap: release announcements and version downloads live on kernel.org, and the homepage of this mirror points there, so nothing in this repository competes with that channel. That split is also why the mirror is useful in the first place, since it gives a GitHub-native view of the stable tree while leaving distribution to the upstream site.

Editorial conclusion

Adopt this mirror if you are a kernel developer, backport engineer, security researcher or hardware vendor who wants the stable tree's source and documentation index in one place. Skip it if you need prebuilt packages or a release announcement feed, and before anything else confirm your build environment provides GNU Make 4.0 or newer.

Frequently asked questions

Official sources

1. gregkh/linux on GitHub
2. Issues
3. Project website
4. README