Panic on reloading a driver with same DEVICE_PROBE() return value

[John Baldwin]

On Tuesday, February 09, 2016 03:17:39 PM Scott Long wrote:
> 
> > On Feb 9, 2016, at 3:00 PM, John Baldwin <jhb at freebsd.org> wrote:
> > 
> > On Tuesday, February 09, 2016 05:45:38 PM Sreekanth Reddy wrote:
> >> Hi,
> >> 
> >> While debugging more, I got one more clue,
> >> 
> >> -----------------------------------------------------------------------------------------------
> >> static driver_t mps_pci_driver = {
> >>        "mpr",
> >>        mps_methods,
> >>        sizeof(struct mps_softc)
> >> };
> >> 
> >> static devclass_t       mps_devclass;
> >> DRIVER_MODULE(mpr, pci, mps_pci_driver, mps_devclass, 0, 0);
> >> -------------------------------------------------------------------------------------------------
> >> 
> >> in the above code snip-set, if I changed "DRIVER_MODULE" line as
> >> DRIVER_MODULE(mpr3, pci, mps_pci_driver, mps_devclass, 0, 0);
> >> (i.e. from "mpr"  to "mpr3") then I am not observing any panic and I
> >> can load & unload the mpr driver multiple times.
> > 
> > Oh, that might be required, yes.  DRIVER_MODULE uses its arguments to define
> > a module name (in this case as "pci/mpr") and module names are required to
> > be unique.  I believe you should be getting a printf warning about this on
> > the console.  Something like:
> > 
> > "module_register: cannot register pci/mpr from blah.ko; already loaded from foo.ko"
> 
> 
> So the problem wasn’t that the malloc was failing, it was that sc was pointing to memory
> that the driver didn’t own, so the fault was happening from assigning sc->facts.  Is there
> something that can be done to make this problem more obvious?  I know there’s a kernel
> printf, like you said, but that’s apparently not a good enough signal.

I'm actually not certain of what triggered the fault.  The check that emits
the printf should also be failing the kldload with EEXIST (but that doesn't
work for the case where both are compiled into the kernel).  The new driver
should have just never been registered, but then I'm not sure how its method
could be called at all.  The only reference to the driver's methods are in the
struct driver which also has the associated softc size (so you shouldn't get
a mismatch between softc size and the driver methods used).

-- 
John Baldwin