DF-5011 run.2.log — CONTROL: same PoC WITH MODULE_DEPEND(dimm,1,1,1)
====================================================================
(fresh boot after the baseline panic; rebuilt deppoc.ko verified to contain
the MDT_DEPEND metadata via `strings -a deppoc.ko | grep -x dimm`)

+ kldstat | grep -E dimm
dimm not loaded (clean state)
+ kldload /root/df5011/deppoc.ko
+ kldstat | grep -E "dimm.ko|deppoc.ko"
 4    1 0xffffffff82600000     1000 deppoc.ko
 5    1 0xffffffff82601000     d000 dimm.ko
    ^^ dimm.ko AUTO-LOADED as a declared dependency
+ sysctl hw.dimminfo | head -3
hw.dimminfo.dimm0.node: 0
hw.dimminfo.dimm0.chan: 0
hw.dimminfo.dimm0.slot: 0
+ kldunload dimm
kldunload: can't unload file: Device busy
+ echo 'CONTROL(deppoc dep+live ref): kldunload dimm rc=1'
CONTROL(deppoc dep+live ref): kldunload dimm rc=1
    ^^ linker refuses: declared dependents are protected
+ sysctl hw.dimminfo | head -1
hw.dimminfo.dimm0.node: 0
+ kldunload deppoc
+ echo 'deppoc clean unload rc=0'
deppoc clean unload rc=0
    ^^ victim destroyed its own reference while dimm.ko still mapped — safe
+ kldstat | grep -E dimm.ko
dimm.ko released after deppoc unload (clean)
+ sysctl hw.dimminfo
sysctl: unknown oid 'hw.dimminfo'

CONCLUSION: MODULE_DEPEND fully protects a user. The unprotected population is
dep-less users — including in-tree ecc_e3.c (sys/dev/misc/ecc/ecc_e3.c:156-157)
— and for them dimm_mod_unload() is the only line of defense, which it fails
to provide (it drains instead of refusing).