#!/bin/sh
# DF-4752 - gpio(4) gpio_unregister resource-leak trigger.
#
# The leak is entirely kernel-side: every gpio_register()/gpio_unregister()
# cycle (controller driver attach/detach) leaks
#   (a) one DEVFS_CLONE_BITMAP(gpio) unit for the master device
#       (gpio.c:573 allocates it; gpio.c:602 destroys the dev but the
#        unit is never put back), and
#   (b) the struct gpio_driver + kstrdup'd name (gpio.c:610 removes it
#       from gpio_driverlist but never kfrees it).
#
# Userland trigger = force the controller driver to detach+re-attach,
# e.g. on a system with `device gpio` + a PC87366 (nsclpcsio):
#     devctl detach nsclpcsio0 && devctl attach nsclpcsio0   (repeat)
# or kldunload/kldload if the controller is built as a module.
# Kernel-side observation: `vmstat -m | grep -i temp` grows by
# struct gpio_driver + name per cycle; DEVFS_CLONE_BITMAP(gpio)
# low bits stay allocated forever.
#
# On the audit guest this is feature-gated: sys/dev/misc/gpio/gpio.c is
# `optional gpio` (sys/conf/files:2119) and X86_64_GENERIC does not
# include `device gpio` (no /boot/kernel/gpio.ko, no /dev/gpio*).

if [ ! -e /dev/gpio ]; then
	echo "SKIP: /dev/gpio absent (gpio(4) framework not in X86_64_GENERIC;"
	echo "      requires kernel with 'device gpio' + a GPIO controller"
	echo "      such as nsclpcsio/PC87366). Defect verified by source"
	echo "      trace + fix compile-validation only."
	exit 3
fi

# Feature present: run the detach/attach cycle and watch M_TEMP growth.
i=0
while [ $i -lt 100 ]; do
	devctl detach nsclpcsio0 2>/dev/null
	devctl attach nsclpcsio0 2>/dev/null
	i=$((i+1))
done
vmstat -m | grep -i temp