LKML is the Linux kernel mailing list, the channel where kernel patches get proposed, argued over, and merged. Read and search it at lore.kernel.org, the official git-backed archive run by kernel.org. lkml.org is a third-party mirror, handy for casual browsing but not the source of truth. So if you are reporting a bug, sending a patch, or chasing a regression, treat lore as canonical and lkml.org as a backup index at best.

Last updated: 2026-07-17

What LKML is and why an email list still runs the kernel

LKML is the main firehose for kernel development. Patches land there, maintainers review them there, and the arguments that shape a release happen there in plain text. It is high volume by design. Thousands of messages a day is normal, and most of them are patches and review, not chatter.

People new to this always ask why the busiest software project on earth runs on email instead of a web platform. The real reason is that email is scriptable, archivable, and works offline. A maintainer can pull a whole patch series into git without a browser, review it in their own client, and reply inline without a rate limit or a login.

This is the bazaar model in practice: open, noisy, and public. Everything happens where anyone can read it. That transparency is the point. A decision you disagree with is sitting right there in the archive, with the reasoning attached.

How do you read LKML without drowning

Do not subscribe to the raw firehose on day one. You will get a few thousand emails and quit. What I do instead is read through lore and filter to the subsystems I care about.

Here is the practical path:

1. Open lore.kernel.org and pick the list that matches your interest. There are hundreds of per-subsystem lists, not just one giant linux-kernel.
2. Read a thread as a threaded web page first, so you see the whole conversation instead of one reply out of context.
3. Subscribe by email only once you know which narrow list you want. linux-mm, linux-usb, and netdev are far more survivable than the main list.
4. Use lore's per-list Atom feed if you want new threads without the inbox flood.

The mistake I see most is treating LKML as one address. It is really a swarm of focused lists, and picking the right one cuts the noise by an order of magnitude.

lore.kernel.org versus lkml.org, and which one to trust

lore is the official archive. It is maintained by kernel.org, backed by git, and every message is a real object you can fetch, verify, and cite. lkml.org is a separate, unofficial mirror that has been around a long time and is fine for a quick look.

The distinction matters the moment you cite something. When you link a thread in a bug report or a commit message, use a lore.kernel.org URL. That link is stable and maintainers trust it. An lkml.org link can rot or lag, and it is not where the maintainers live.

In short: lkml.org is a convenience, lore is the record.

Searching LKML for a specific patch, thread, or error

Search on lore first, because its query syntax is real and its data is git. The search box takes structured terms, not just keywords. You can scope by sender, subject, and message id, and the URL carries the query so you can share or script it.

A few searches I run constantly:

1. s: matches a subject fragment, for example s:"NULL pointer" when I have the panic line.
2. f: filters by a person, like f:torvalds, when I want one maintainer's take.
3. nq runs a plain full-text search when I only have an error string from dmesg.
4. The message-id straight from an email header jumps you to the exact thread.

Because lore is a public-inbox archive, every list is also a git repo you can clone and git grep offline. That is the trick when web search is not specific enough. Pull the repo, grep the raw messages, and you have the whole list on disk.

For pulling actual patches rather than reading them, reach for b4, a tool built to make a patches-and-mailing-list workflow easier for developers and maintainers. b4 am <message-id> fetches a full series, threads it correctly, and hands you a clean mbox to git am. It beats copy-pasting patches out of a browser every time.

Reporting a kernel bug the right way

A good bug report is reproducible and lands on the right list. Before you write a word, gather evidence. A report that says "USB broke" gets ignored. A report with the exact kernel version, the dmesg lines, and a reproducer gets a reply.

Here is the order I work in:

1. Reproduce it and capture the kernel's own words. dmesg -T | tail -40 right after the failure usually has the real message. Photograph the console if it panics and scrolls off.
2. Note the exact kernel version with uname -r, and whether a recent update triggered it. If an older kernel is clean, say so. That tells the maintainer it is a regression, not hardware.
3. Find the owning subsystem. Run scripts/get_maintainer.pl against the file or patch in the kernel tree. It reads the MAINTAINERS file and prints the exact people and lists to CC.
4. Write the report: what you did, what happened, what you expected, the logs, and the reproducer. Keep it plain text.

Send it to the subsystem list, not just the giant linux-kernel list. The person who owns that driver reads their own list far more closely than the firehose.

How do you subscribe and post without getting ignored

You want your patch etiquette to help your changes land cleanly without endless back-and-forth. The submission process feels heavy at first. The documentation, submit-checklist.rst, and driver notes all matter. Expect practical commands, short checklists, and the reasoning that gets your work merged with less friction.

The mechanics are old-school on purpose. Subscribe to a subsystem list through its listinfo page, then send plain text only. No HTML, no attachments, no top-posting. Maintainers quote your text inline and reply between the lines, and HTML mail breaks that cold.

What a good post looks like:

• Plain-text, inline patches generated with git format-patch, sent with git send-email.
• A subject with a subsystem prefix and [PATCH], for example [PATCH] usb: fix stall on resume.
• A Signed-off-by: line, which is your sign-off under the Developer's Certificate of Origin.
• One logical change per patch, so it can be reviewed and reverted on its own.

Run checkpatch.pl before you hit send. It is a perl script that checks patches for trivial style violations and can correct some of them for you. It will not make a bad patch good, but it clears the noise so reviewers argue about your logic instead of your whitespace.

Then wait. Send the series, and give it about a week before a polite ping. Reviewers are volunteers with day jobs, and silence usually means busy, not rejected.

Why lore shows an Anubis challenge page

That interstitial page is expected, not a sign lore is broken. lore.kernel.org runs an anti-scraping check called Anubis to fend off the wave of aggressive AI crawlers hammering the archive. A normal browser solves it and moves on within a second or two.

It only becomes a problem for automation. If you scrape lore with a naive script or a bare curl, the challenge blocks you. The fix is not to fight the web page. Use the git interface instead: clone the public-inbox repo for the list, or pull messages with b4. Those paths were built for machines and do not hit the Anubis wall.

So if a script that worked last month suddenly returns an HTML challenge instead of a message, that is your signal to move off scraping and onto git.

Tracing an LKML thread back to the actual fix

This is the habit that pays off: never stop at the reply that sounds authoritative. Follow the thread into the actual patch, then read the diff against your own failure.

Here is what I do when a thread claims to fix my problem. I pull the referenced patch with b4 or grab the commit id from the thread. Then I open that diff in the kernel tree and read what it changes. Half the time the "fix" touches a different code path than the one my strace and dmesg point at, and it would not have helped me at all.

Cross-check against your own evidence. If your logs show the failure in one function and the patch touches another, the thread is not your answer no matter how confident the reply reads. Match the patch to the code path in your trace, then apply it and confirm the failure is gone. A fix you cannot tie back to your own reproducer is a guess. LKML gives you the whole chain from complaint to commit in public, so use all of it, not just the loudest message.

FAQ

How do I subscribe to the Linux kernel mailing list by email?

Go to the listinfo page for the specific subsystem list you want and follow its subscribe instructions, usually a confirmation email round-trip. Skip the main linux-kernel list unless you genuinely want everything. Start with one narrow list, confirm you can keep up, and add more later.

Is lkml.org the same as the official kernel archive?

No. lkml.org is a long-running independent mirror, useful for a fast look but not maintained by kernel.org. The official archive is lore.kernel.org, which is git-backed and stable. When you need a link that will still resolve in five years, use lore.

What does checkpatch.pl actually check?

It scans a patch for trivial style problems like spacing, line length, and common formatting mistakes, and can correct some of them automatically. It reports ERROR, WARNING, and CHECK levels. Clean it up before sending, but do not treat a passing run as proof the patch is correct. It checks form, not logic.

How do I track a patch series after I send it?

Watch it on Patchwork, a patch tracking system for community-based projects that many subsystems run to follow a patch from submission to merge. It shows the review state, so you are not re-reading the whole thread to find out where your series stands.

Why is LKML still email instead of a web forum or pull requests?

Because email is offline-capable, scriptable, and permanently archived, and tools like git am, git send-email, and b4 are built around it. A maintainer can review and apply a series without a browser or a login. The workflow is old, but it scales to thousands of messages a day in a way web forms never have.

Related on this blog

• Enable Kernel CONFIG Options
• How to Contribute to the Linux Kernel: A Guide
• Ensure GPL Compliance in Kernel Code