Hildenbrand rejects van Riel mm series as AI-generated slop

David Hildenbrand has refused to review Rik van Riel's RFC series that would let remote process memory reads take the per-VMA lock instead of holding the mmap read lock for the whole transfer, calling the submission AI slop that violates how mm selftests are supposed to be written.

The series targets a real operational pain: on large machines running big multi-threaded applications, mmap() or munmap() in one thread stalls readers of /proc/PID/cmdline, environ, mem, and process_vm_readv even when the pages they need are resident. Van Riel's approach looks up the VMA, untags the remote address without the mmap lock, and walks under the per-VMA lock when the range fits one VMA, falling back to the mmap lock otherwise. He also batches PTE-mapped multi-size THP so the slow pin_user_pages path walks a contiguous folio run once, reporting roughly 7.6x faster long-term pins on 64 kB mTHP in gup_test, with smaller gains on ordinary remote reads.

Every patch in the posting carries Assisted-by: Claude:claude-opus-4.8. Hildenbrand objected that a dedicated mthp GUP/COW selftest is the wrong shape, that testing implementation details is not what mm wants, and that existing tests should cover mTHP naturally. He pointed at Documentation/process/coding-assistants.rst: contributors must review all AI-generated code and take full responsibility. Mike Rapoport had already asked that the new test use the standard ksft helpers, with a parenthetical about instructing Claude. Suren Baghdasaryan still reviewed several preparatory patches. John Hubbard separately flagged a double macro evaluation and a misleading READ_ONCE under a write lock.

Van Riel offered to drop the independent batching change for a follow-up. The reliability goal remains: stop system monitors from wedging under mmap lock contention precisely when their output is most needed.