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

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