mm maintainer NAKs THP compaction series over undisclosed LLM use

Memory management maintainer Lorenzo Stoakes has rejected a two-patch series meant to stop the kernel from repeatedly running failed asynchronous compaction on transparent huge page (THP) faults, citing undisclosed large language model assistance and Linux kernel policy on generated contributions.

The patches, from Qiliang Yuan, targeted a real cost on MADV_HUGEPAGE mappings. A THP fault first tries the local node with a single async direct compaction pass. When that node is fragmented by unmigratable memory, such as long-term RDMA pins, a failed async run is never deferred, so every 2 MiB fault rescans the zone before falling back elsewhere. Yuan reported that filling a 4 GiB huge-page buffer on a pinned, fragmented node dropped direct compactions from hundreds to a handful and cut time in compaction from well over 100 ms to a few milliseconds, at the price of placing somewhat fewer THPs on the local node.

Stoakes NAKed the series as buggy and said it had tripped an AI-detection check. Kernel process rules require contributors to disclose automated help with an Assisted-by tag, and to understand and defend every change they send. Maintainers may reject generated work without detailed review when that bar is not met. Stoakes pointed to coding-assistant and generated-content guidance in the kernel docs, and to the expectation that newcomers build familiarity with smaller changes before large cross-cutting work.

He noted that Yuan’s first mail arrived in late September and was followed by a rapid stream of complicated series across KVM, ext4 and jbd2, blk-mq, ublk, BPF, and migrate paths, after a silent switch from an earlier address that had shown similar patterns. With only a handful of prior commits and several glaring flaws already visible in this series, Stoakes said he lacked confidence the author understood the code and asked the contributor to focus on smaller changes.

The rejection underscores how mm and other core maintainers are treating disclosure and authorship responsibility as hard gates, not optional etiquette, as LLM-assisted patch volume rises on kernel lists.