# DF-4819 — i915 GEM shrinker is never registered with any reclaim path (DF-4507 family)

## What this is

Structural verification that the i915 GEM shrinker in the DragonFly DRM port
**can never run from system memory reclaim**:

1. `sys/dev/drm/include/linux/shrinker.h` (the DFly linux-compat shim) declares
   only `struct shrinker` + `SHRINK_STOP` — **`register_shrinker` does not
   exist at all** in the shim (or anywhere in `sys/`).
2. The i915 port compensates by `#if 0`-ing out every registration call site:
   `register_shrinker`, `register_oom_notifier`, `register_vmap_purge_notifier`
   (`sys/dev/drm/i915/i915_gem_shrinker.c:521-532`).
3. The `i915_gem_shrinker_count` / `i915_gem_shrinker_scan` bodies are `#if 0`
   stubs that `return 0` (lines 313-351, 353-395); even the function pointers
   installed by `i915_gem_shrinker_register()` point at dead stubs that nothing
   will ever call.
4. The only global pressure hook that exists in the DRM tree
   (`vm_lowmem`, registered by `sys/dev/drm/ttm/ttm_page_alloc.c:447`) is never
   `EVENTHANDLER_INVOKE`'d anywhere in the kernel (0 sites in `sys/`).

Net effect: an unprivileged user with `/dev/dri` access on i915 hardware can
hold gigabytes of shmem-backed GEM pages (including `I915_MADV_DONTNEED`
"purgeable" objects that userspace explicitly marked reclaimable) that the VM
subsystem **cannot reclaim under memory pressure** — the box goes to the OOM
killer instead of purging GPU memory. Same defect family as DF-4507 (TTM page
pools) and complements it: DF-4507 = pool pages, DF-4819 = i915 GEM object
pages.

## Build

Nothing to compile — this is a code-structure defect. The verification is a
shell script:

    ./build.sh          # no-op (explains why)

## Run

    ./run.sh            # static proof against the workspace sys/ tree
    # binary proof on a DragonFly guest:
    sh check_shrinker_wiring.sh --module /boot/kernel/i915.ko

## Expected output

- Host static: six `PASS` lines — no `register_shrinker` in shim; registration
  `#if 0`'d; count/scan bodies `#if 0` (return 0); `vm_lowmem` invoked 0 times;
  live `i915_gem_shrink` callers are explicit only (get_pages failure paths at
  i915_gem.c:2935, i915_gem_gtt.c:2449, freeze paths at i915_gem.c:6324/6353).
- Guest binary: `nm i915.ko` shows `i915_gem_shrinker_count/scan` as local
  (`t`) stubs and **no** `register_shrinker` symbol/undefined reference;
  `nm drm.ko` shows no such symbol either.

## Runtime impact demonstration

**Not possible on this audit guest**: it runs QEMU std VGA (`chip=0x11111234`),
i.e. no Intel GPU, so i915 never attaches (`kldstat` clean). The DoS impact
(unreclaimable GPU memory under pressure) requires real i915 hardware.
This matches the precedent set by DF-4507 (recorded `untested` for the same
reason). The code-level defect itself is *certain* — proven statically and
against the compiled module binary.