DF-5617 — ig4_acpi.c attach-error unwinder re-enters the leaked serializer (ACPI twin of DF-5601)

Status: reproduced (kernel panic through production code) | fix validated (A/B)

What

ig4iic_acpi_attach() sets sc->pci_attached = 1 at ig4_acpi.c:127 before calling ig4iic_attach(sc) (ig4_acpi.c:132). When ig4iic_attach() fails on its bus_setup_intr() path — which returns with the serializer still held (ig4_iic.c:648-655 has no lwkt_serialize_exit() on the error branch — the root defect filed as DF-1049/DF-5601) — the unwinder ig4iic_acpi_detach(dev) (ig4_acpi.c:134 → :146-151) calls ig4iic_detach(sc), whose first action is lwkt_serialize_enter(&sc->slz) (ig4_iic.c:678) — a re-entry of a self-held, explicitly non-recursive serializer (sys/serialize.h:41-42): KKASSERT panic on INVARIANTS kernels, hard self-deadlock otherwise.

Rig — two halves

(A) Real-path proof: planted ig4 ACPI device (no harness code in the path)

ssdt_ig4p.asl (generated by gen_ssdt.py, compiled with the guest's iasl) declares \_SB.I2C8/I2C9 with HID INT33C2 (first entry of ig4iic_ids[], ig4_acpi.c:71) and a _CRS whose Memory32Fixed window points into the SSDT's own AML pad buffer (QEMU places the appended SSDT at 0xBFFE1CAC — guest-RAM-backed but outside SMAP "System RAM", so ram_attach() (nexus.c:653-705) has not reserved it and the allocation succeeds; SMAP-resident windows are refused by the rman — observed live). The pad carries COMP_VER=0x3131352A so the IG4_ATOM compat gate passes.

QEMU_EXTRA="-acpitable file=$PWD/ssdt_ig4p.aml" dfbsd-qemu/vm.sh up
vm.sh run_root 'kldload ig4'

Observed (run.log / dance logs): the REAL ig4iic_acpi_probe matches the HID, the ACPI _CRS translation yields iomem ... irq N on acpi0, MMIO alloc succeeds, and ig4iic_attach() (ig4_acpi.c:132) runs the full register dance on the crafted device — reaching bus_setup_intr() with the latch supplied by latch_dance.py (the DW ENABLE_STATUS 0x6C→0x9C latch does not exist in RAM; the host plays it via QEMU monitor gpa2hva + /proc/<qemu>/mem):

ig4iic0: <Designware I2C Controller> iomem 0xbffe1cdc-0xbffe2cdb irq 17 on acpi0
ig4iic0: version 1 type 33c2d0c0 params 00000000 general 00000000 comp_version 3131352a
ig4iic0: <Designware I2C Controller> [attached!]      <- full attach, all gates passed

Every step of ig4_acpi.c:99-132 is real and live on this guest. The only input that never occurs naturally on the QEMU rig is a bus_setup_intr() failure (every reachable GSI deterministically avoids an exclusive-owner conflict: the _CRS parser drops GSIs above the legacy map — acpi_resource.c:599 machintr_legacy_intr_find — and the IOAPIC auto-router picks handler-free (cpu, gsi) slots). On real hardware the failure is any rman_activate_resource() error or register_int() == NULL (nexus.c:519-532, e.g. an exclusive-owner GSI conflict), which is exactly what DF-5601 cited for the PCI twin.

(B) The panic: production ig4iic_attach/ig4iic_detach through the ig4_acpi.c unwinder

df5617.c (built by build_kld.sh with df56.c, the DF-5601 pseudo-bus whose bus_setup_intr returns EINVAL — the failure injection) replays ig4iic_acpi_attach()'s prologue line-for-line (ig4_acpi.c:104-127, no bzero — the DF-5600 twin-check; softc is M_ZERO-allocated by newbus, subr_bus.c:1953), calls the REAL ig4iic_attach() (stock ig4.ko) on a fake register file with a mirror kthread emulating the ENABLE_STATUS latch, then replays ig4_acpi.c:133-134's unwinder into the REAL ig4iic_detach().

vm.sh run_root 'kldload ig4 && kldload df56.ko && kldload df5617.ko'

Baseline (stock kernel, run.log / panic.txt):

df5617ig40: Unable to setup irq: error 22                     <- ig4_iic.c:652
DF5617: ig4iic_attach() = 22 (EINVAL from bus_setup_intr)
DF5617: serializer is HELD by the ig4_iic.c:648-655 error path (IS_SERIALIZED: 1)
DF5617: replaying ig4_acpi.c:133-134 unwinder -> ig4iic_acpi_detach() -> ig4_acpi.c:146-147 ig4iic_detach()
panic: assertion "!IS_SERIALIZED((s))" failed in lwkt_serialize_enter at lwkt_serialize.c:107
lwkt_serialize_enter() at lwkt_serialize_enter+0x8c
ig4iic_detach() at ig4iic_detach+0x1f
df5617_attach() at df5617_attach+0x1d8
device_doattach() at device_doattach+0x3af

Guest wedged in DDB (vm.sh status ⇒ down) — boot/kldload-time kernel panic.

Fix validation (A/B, same kernel config)

fix.diff (identical to DF-5601's verified one-liner) adds the missing lwkt_serialize_exit(&sc->slz) on ig4_iic.c's setup-intr error path — the root of the chain both files' unwinders trip on. Patched ig4.ko built in the guest (fix_build.log), identical scenario re-run (run-fixed.log):

DF5617: serializer is released by the ig4_iic.c:648-655 error path (IS_SERIALIZED: 0)
DF5617: ig4iic_acpi_detach replay = 0 -- returned cleanly, NO PANIC (fix effective)

Guest stayed up. Baseline panic vs patched clean return: fix_status = fixed.

Impact

Boot-time or kldload ig4-time kernel panic / hard hang on any system where the ACPI-enumerated ig4 controller's IRQ setup fails once (exclusive-owner GSI conflict, rman activation failure). Availability bug — not unprivileged-triggerable (needs the driver attached to a failing GSI / crafted firmware): Low, consistent with DF-1049/DF-5601.

Rig lessons

1. SMAP RAM-backed _CRS MMIO windows are refused by the nexus rman (ram_attach reserves all System RAM) — point planted windows into the fw_cfg ACPI table area (0xBFFC0000-0xBFFFFFFF), which is RAM but not SMAP; the appended SSDT's own bytes are the natural deterministic backing.
2. The window must be ≥ 0x810 bytes: ig4_iic.c:504-508 unconditionally reads IG4_REG_GENERAL at +0x808; a 0x200 window page-faults the kernel (observed live — Fatal trap 12 ... ig4iic_attach+0x12c: movl 0x808(%rdx)).
3. iasl places AML buffer data at file offsets that shift with content — locate the register file with an embedded marker, recompute the window, recompile; the SSDT base itself (0xBFFE1CAC) is stable across boots.
4. QEMU monitor gpa2hva + /proc/<qemu-pid>/mem (ptrace_scope=0) gives sub-millisecond physical writes — resolve the hva before the trigger; memwrite latency (0.3-0.6 s per monitor round-trip) is too slow for the 100-tick poll windows.

Fix status (batch validation)

Applied with the 36 sibling fix.diffs of this batch in findings/poc/_batch41/all_fixes.patch; single in-guest make -j6 nativekernel KERNCONF=X86_64_GENERIC completed RC=0 with zero errors under -Werror (full log: findings/poc/_batch41/fix_build8.log). Behavior A/B intentionally skipped for this Info-tier item.