re: CVS commit: src/sys/dev/scsipi

[matthew green <mrg%eterna.com.au@localhost>]

> > > Module Name:      src
> > > Committed By:     bouyer
> > > Date:             Wed Apr 18 20:37:49 UTC 2012
> > > 
> > > Modified Files:
> > >   src/sys/dev/scsipi: scsipi_base.c
> > > 
> > > Log Message:
> > > Fix KASSERT(): autoconf doesn't run under the KERNEL_LOCK
> > 
> > this is true, but can you please fix it differently?  ie autoconf
> > isn't "cold".  most of scsi autoconf runs after cold is gone, so
> > i'd rather make whatever callers deal with it so that they work
> > cold or not.
> 
> But if we're not cold, interrupts are enabled so I hope whatever calls
> into scsi autoconf runs under the big lock if the underlying driver
> isn't SMP-safe (and if it is, it's its job to take the KERNEL_LOCK).

the point of the KASSERT()'s it to make sure that, until scsipi is
made smp safe, calls into scsi are all done with the kernel lock.

> The problem I've seen is with a driver I'm working on, similar to mfi(4)
> (and I suspect mfi(4) would have had the same problem):
> the driver's attach calls config_found_sm_loc() to attach the scsibus
> while cold, so the big lock isn't helt at this point.

yeah - i'm pretty sure i've seen this and fixed it in a few other
places rather than the above change.

> If the driver's attach is called after cold (e.g. after a detach/rescan
> of the pci bus), the driver's attach should be called with KERNEL_LOCK
> held, or bad things may happen when interrupts are enabled for this driver.

there should be no reliance on "cold" being set for normal driver
attach.  it might be a module loaded after boot.  how ever the
driver is loaded, it will need to work without cold being set.

in my mind, the scsi code should try to run regardless of the value
of "cold" and that's why i replied above.

> What kind of senario do you have in mind ?

modules, as above.  or simply drvctl -d / -r.  IMO, only platform
specific code really should depend upon cold.  "scsipi", as a
relatively high level subsystem, should not.

thanks.


.mrg.