# DF-4516 — cross-device PRIME import panics the kernel via dma_buf_detach stub

## What
`drm_gem_prime_import_dev()` (sys/dev/drm/drm_prime.c:709-762) attaches with
`dma_buf_attach()` (drm_prime.c:733). On this port `dma_buf_attach()` is a stub that
returns **NULL, not ERR_PTR** (sys/dev/drm/include/linux/dma-buf.h:96-101), so the
`IS_ERR(attach)` guard at drm_prime.c:734 does not fire. The code proceeds, the subsequent
`dma_buf_map_attachment(NULL, …)` returns `-EINVAL` (linux_dma-buf.c:196-197), and the
error unwind `fail_detach:` calls `dma_buf_detach()` (drm_prime.c:758) — which is
hardcoded to `panic("dma_buf_attach is not implemented")` (dma-buf.h:125-130).

Any **foreign** dma-buf (i.e. exported by another DRM device) imported through a driver
that uses the generic import helper — radeon (radeon_drv.c:699) and amdgpu
(amdgpu_prime.c:445-458 falls through to drm_gem_prime_import) — instantly panics the
kernel. i915 has its own copy (i915_gem_dmabuf.c:305-321) that swallows the NULL attach
and instead creates a zombie object with `import_attach == NULL`.

## Files (shared trigger with DF-4515)
- `df4515mod.c` — `sysctl hw.df4515mod.fire=6` runs exactly drm_prime.c:733→739→758
- `run.log`, `panic.txt` — baseline: `panic: dma_buf_attach is not implemented`
- `fix_run.log` — after fix.diff: `dma_buf_attach -> ERR_PTR(-ENOSYS), IS_ERR=1`, no panic
- `fix.diff` — stub returns `ERR_PTR(-ENOSYS)`; detach stops panicking

## Reproduce (as root in the guest)
```
cd /usr/src/sys/dev/drm/drm && make obj && make
cd /root/df4515 && make
kldload /usr/obj/usr/src/sys/dev/drm/drm/drm.ko
kldload df4515mod.ko
sysctl hw.df4515mod.fire=6      # EXPECT: panic: dma_buf_attach is not implemented
```
Note: the real entry (DRM_IOCTL_PRIME_FD_TO_HANDLE with a foreign prime fd) requires two
DRM devices; the QEMU guest has none, so the PoC drives the identical call sequence
through the shipped drm.ko symbols.