# DF-5018 — radeon_mn.c is dead code: excluded from every build, and cannot compile if re-enabled

## What

`sys/dev/drm/radeon/radeon_mn.c` — the radeon MMU-notifier / userptr
invalidation path — is **not compiled anywhere** in DragonFly:

* kernel build: `sys/conf/files:2557-2558` — the file is commented out
  ("Only build radeon_mn.c if CONFIG_MMU_NOTIFIER is set");
* radeon KMOD build: `sys/dev/drm/radeon/Makefile:107` — `#	radeon_mn.c`;
* `sys/dev/drm/kconfig.h` never defines `CONFIG_MMU_NOTIFIER`, so
  `radeon.h:1794-1803` compiles the *stub* versions:
  `radeon_mn_register()` returns `-ENODEV`, `radeon_mn_unregister()` is a
  no-op. The GEM userptr ioctl path (radeon_gem.c:339) therefore can never
  reach this file on any DragonFly system;
* guest-verified: `nm /boot/kernel/radeon.ko | grep -c radeon_mn` = 0,
  `nm /boot/kernel/kernel` = 0 (see evidence.txt).

Additionally, the file **cannot be resurrected as-is**: it uses a
`bool blockable` parameter (radeon_mn.c:125) and calls
`__mmu_notifier_register` (radeon_mn.c:227) and `mmu_notifier_unregister`
(radeon_mn.c:90), none of which exist in DragonFly's compat layer
(`sys/dev/drm/include/linux/mmu_notifier.h` declares a 4-arg
`invalidate_range_start` with no `blockable`, and no register/unregister
functions exist anywhere in the tree — verified by grep). Enabling it
without first porting a real mmu_notifier implementation is a
compile/link error, not a runtime path.

## Why this is a finding (pass 2)

Pass 1 recorded no findings for this file. The pass-2 value is the durable
record that (a) every `bo->mn` / userptr-invalidation hazard in radeon is
**unreachable** on DragonFly as shipped, and (b) the latent hazards below
exist should anyone wire the notifier up.

## Latent hazards if ever re-enabled (documented, not reachable)

1. **AB-BA lock order**: `radeon_mn_invalidate_range_start` holds
   `rmn->lock` while reserving BOs (`radeon_bo_reserve`, line 162) and
   validating them (line 174, takes `bo->tbo.resv`); `radeon_mn_unregister`
   takes `rdev->mn_lock` → `rmn->lock` and is called from the BO teardown
   path which can hold reservation objects. Invalidate(regv) vs
   teardown(mn_lock) can deadlock.
2. **`end -= 1` wrap** (line 133): an `invalidate_range_start` call with
   `start == end == 0` wraps `end` to ULONG_MAX and matches the entire
   interval tree, stalling on every registered BO.
3. **No refcount on `rmn`** returned by `radeon_mn_get` — lifetime is bound
   to `mm` teardown serialization only.

## Verification

No runtime PoC is applicable (nothing to trigger). The dead-code claims are
machine-verified on the audit guest — `evidence.txt`:

```
== radeon_mn in kernel build? ==   sys/conf/files:2557-2558 (commented out)
== radeon_mn in module Makefile? == radeon/Makefile:107 (commented out)
== CONFIG_MMU_NOTIFIER in kconfig.h? == 0 (ABSENT)
== radeon_mn symbols in built radeon.ko == 0 ; in kernel == 0
```

## Recommended action

Either delete the file (matching its build status) or port a real
mmu_notifier compat layer before re-enabling — and fix the three latent
hazards above at the same time. Severity: Info (defense-in-depth /
dead-code hygiene; no runtime attack surface today).

---

## Status: UNTESTED (by design — Info/dead-code finding, no runtime PoC applicable)

The finding's claims are source- and image-level and were machine-verified
(evidence.txt): the file is absent from the kernel build (sys/conf/files:2557-
2558), absent from the radeon KMOD (radeon/Makefile:107), CONFIG_MMU_NOTIFIER
is undefined (kconfig.h), the stubs in radeon.h:1794-1803 are what actually
compile, and no radeon_mn symbols exist in /boot/kernel/radeon.ko or the
kernel image. Nothing can be executed; there is no trigger, no panic, no
leak. The correct disposition is Info severity, no fix validation.

## 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.

(No fix.diff for this item: documented recommendation only - see Fix above.)