newbus: Push down the locking in driver_module_handler

[imp]

Summary

Hold the topo lock over the calls to newbus, but not for chaining
function. Also, we should only create the devclase for MOD_LOAD, but not
for any other case. This also avoids calling any newbus functions for
module unknown MOD_ cases (which in practice is no actual chanage).

Sponsored by: Netflix

[markj]

sys/kern/subr_bus.c

5298

Why exactly don't we want to hold the lock here?

What's an example of a chainevh in the tree? I can't find any uses with a quick look, but I'm probably missing something obvious.

[imp]

sys/kern/subr_bus.c

5298

That's because it's set in a macro that's used all over the place, but often takes NULL parameters.
grep -r sys/dev MOD_LOAD: gives a good proxy for what to grep for. Many of them are for DEV_MODULE which is for dev_t not device_t.
Others are for DEVICE_MODULE where the next to last parameter is non NULL.
Some clearly require locking. Others ambiguously require it, but maybe not. Some are safe. I'm thinking for the first round we may want to keep the topo lock over these calls.
.... but some newer ones like nvmf look like they should be called unlocked.
So maybe I need to do a careful audit before proceeding. Today we call them all with Giant locked though.

5298

oh, and things like

moduledata_t icl_soft_data = {
        "icl_soft",
        icl_soft_modevent,
        0
};