Giant is implicitly released when the owning thread goes to sleep, which
makes it unsuitable as a general purpose lock. For instance, if two
threads race to call BUS_RESCAN()->pci_reset_method() on the same bus,
and one of them sleeps while invoking device_detach(), double frees
are possible. It's quite ordinary for a DEVICE_DETACH implementation to
sleep and thus release Giant, e.g., by calling device_destroy(), which
can sleep for several reasons.
Use a second sleepable lock to cover this case. Acquire it when
invoking module load handlers or SYSINITs, since many consumers require
that.
With this patch I see a LOR report from witness, between bus_topo_sx and
"USB config SX lock", which occurs during USB bus enumeration, but I
believe this is a false positive. Nested usbd_enum_lock() calls can
occur when enumerating ports on a hub; in each case the USB device is
different, but since all of the config locks belong to a single class,
witness thinks that both lock orders are possible.
This is a WIP and is not intended to be committed as-is; at the very
list, all platforms need to be updated to acquire the lock when invoking
root_bus_configure().