# DF-0032 — guest environment for this verification
# Captured after the demonstration (guest since reset to clean-install).

uname: DragonFly dfbsd 6.5-DEVELOPMENT DragonFly v6.5.0.1712.g89e6a-DEVELOPMENT #1: Mon Jun 29 14:18:01 UTC 2026     root@ephemeral-5c2002c44b6c:/usr/obj/usr/src/sys/X86_64_GENERIC  x86_64
cc: cc 8.3 [DragonFly] Release/2019-02-22

kern.maxproc = 4036
kern.maxprocperuid = 1009
kern.maxfiles = 64576
kern.maxfilesperproc = 16144
hw.physmem = 2110652416          # ~2 GB
vm.kvm_size = 8795004596224      # ~8 TB (kernel_map)

# Per-type kmalloc limit relevant to the trigger:
#   M_FILEDESC ks_limit = kmem_lim_size()/10 = min(physmem, kvm_size)/10
#                       = min(2GB, 8TB)/10 = ~195 MB
#   (verified live: `vmstat -m | grep file_desc` shows Limit 195M)
#
# fdcopy() is the ONLY fd op whose struct-filedesc kmalloc can fail: it uses
# M_WAITOK|M_ZERO|M_NULLOK (kern_descrip.c:2481-2486), so it returns NULL when
# M_FILEDESC memuse >= ks_limit (kern_slaballoc.c:863-879). fdinit()/fdshare()
# and fdcopy's fd_files[] array use plain M_WAITOK (no M_NULLOK), so they would
# panic on limit exhaustion instead -- which is exactly why the leak point is
# the fdcopy newfdp allocation.

# VM ran under KVM: qemu-system-x86_64 -enable-kvm -m 2048 -smp 2
# Serial console (comconsole) baked into the clean-install baseline; kernel
# boot/panic output is captured in dfbsd-qemu/boot.log on the host.