DF-3865 — DragonFly rbtree shim never maintains rb_root_cached.rb_leftmost; amdgpu_vm_fini()'s mapping-cleanup loop is dead code → permanent mapping leak

Files: sys/dev/drm/amd/amdgpu/amdgpu_vm.c (fini loop), sys/dev/drm/include/linux/rbtree.h (shim)

Root cause

The DFly compat shim implements the Linux leftmost-cached rbtree API without the cache:

• rbtree.h:100-101 rb_insert_color_cached(node, root, leftmost) — macro ignores the leftmost argument and only runs INSERT_COLOR; it never writes root->rb_leftmost.
• rbtree.h:102-103 rb_erase_cached(node, root) — only RB_REMOVE; never updates root->rb_leftmost.
• rbtree.h:104 rb_first_cached = RB_MIN over the real tree (correct).
• rbtree.h:175 LINUX_RB_ROOT_CACHED initializes rb_leftmost = NULL.

Consequently rb_root_cached.rb_leftmost is NULL for the lifetime of the tree. amdgpu_vm_fini() (amdgpu_vm.c:3316-3334) replaced the upstream postorder cleanup with:

    while (vm->va.rb_leftmost) {          /* amdgpu_vm.c:3325 — never true */
        mapping = container_of((void *)vm->va.rb_leftmost, ...);
        list_del(&mapping->list);
        amdgpu_vm_it_remove(mapping, &vm->va);
        kfree(mapping);
    }

The loop body never executes: any amdgpu_bo_va_mapping still in the interval tree at VM teardown is silently leaked (its 72-byte allocation plus rb node), and the dev_err("still active bo inside vm") case (amdgpu_vm.c:3313-3315) degenerates to leak-without-cleanup. This is a DragonFly-specific divergence (upstream uses rbtree_postorder_for_each_entry_safe, which works).

Normally the tree is empty at fini because the GEM close path removes all mappings; the leak manifests for mappings added by kernel-internal callers or any close-ordering that leaves stray mappings (KFD paths).

Fix

fix.diff swaps the dead loop for an rb_first()-based walk (RB_MIN works under the shim). The shim macros should also grow real leftmost maintenance for other future users — the same broken pattern is latent for anyone else using rb_leftmost directly.

DF-3865 VERDICT — not_reproduced (hardware-gated); shim defect certain at source

Runtime

No AMD GPU on the audit guest → no VM is ever created → fini path never runs. status = not_reproduced, reproduced = 0. (The defect is provable purely from the shim macros; no execution needed.)

Source proof

1. sys/dev/drm/include/linux/rbtree.h:100-101:

#define rb_insert_color_cached(node, root, leftmost)            \
    linux_root_RB_INSERT_COLOR((struct linux_root *)(&(root)->rb_root), (node))

The leftmost parameter is discarded; no write to root->rb_leftmost anywhere in the macro.

2. rbtree.h:102-103: rb_erase_cached likewise only removes.

3. rbtree.h:175: #define LINUX_RB_ROOT_CACHED (struct rb_root_cached) { {NULL, }, NULL } → rb_leftmost starts NULL and stays NULL forever.

4. amdgpu_vm.c:3055 vm->va = LINUX_RB_ROOT_CACHED; → NULL leftmost. amdgpu_vm.c:3316-3334 (the DragonFly branch) loops while (vm->va.rb_leftmost) — dead; the kfree at 3333 is unreachable. Upstream v4.20 uses rbtree_postorder_for_each_entry_safe here (verified) — the DFly replacement is the divergence.

5. Consequence: every mapping still present in vm->va at fini leaks (kfree skipped). Affected scenario: fini with non-empty tree (amdgpu_vm.c:3313 even prints "still active bo inside vm" for it).

Severity Low (bounded leak, rare path, no memory-safety violation), but a real, certain shim-contract bug — and a landmine for any other code that trusts rb_leftmost under this shim.

Fix validation

fix.diff replaces the dead loop with an rb_first()-based loop (rbtree.h:97 rb_first = RB_MIN — functional under the shim); git apply --check clean. Not exercisable on this guest: fix_status = not_testable.

Fix status (batch validation)

Applied with the 36 sibling fix.diffs of this batch in findings/poc/_batch41/all_fixes.patch; single in-guest make -j6 nativekernel KERNCONF=X86_64_GENERIC completed RC=0 with zero errors under -Werror (full log: findings/poc/_batch41/fix_build8.log). Behavior A/B intentionally skipped for this Info-tier item.