Page MenuHomeFreeBSD

mpi3mr: Wait for pending IOCTLs to drain completely on driver unload
Needs ReviewPublic

Authored by chandrakanth.patil_broadcom.com on Sun, Oct 4, 1:22 PM.

Details

Summary

During driver unload or module detach, the driver previously waited for
pending management IOCTLs to complete but capped the wait loop to a fixed
180-second timeout. If a long-running management command (such as firmware
flashing, diagnostic dump collection, or secure erase) took longer than 180
seconds, the detach sequence proceeded while the IOCTL was still actively
executing. This led to tearing down hardware resources, destroying mutexes,
and freeing driver memory structures while userland was still using them,
causing memory corruption.

Remove the arbitrary 180-second timeout and wait until all pending IOCTLs
have fully completed before proceeding with resource teardown. Because
all IOCTL commands have individual hardware timeouts, they are guaranteed
to complete or time out deterministically.

Test Plan
  • Clean build with WERROR=-Werror across FreeBSD 16, 15, and 14 with INVARIANTS/WITNESS enabled; git bisect verified.
  • Tested driver unload cycles while executing long-running StorCLI2 diagnostic and firmware management commands on SAS4116/SAS5116 controllers.
  • Verified that driver detach waits cleanly for active commands to finish before releasing hardware resources and driver memory.

Diff Detail

Lint
Lint Skipped
Unit
Tests Skipped

Event Timeline

sys/dev/mpi3mr/mpi3mr_pci.c
739

This strikes me as unsafe. We might hang here if there's a stuck ioctl, missed wakeup or similar bug.