On Thu, Feb 28, 2013 at 09:43:49AM +0100, Manuel Bouyer wrote: > On Thu, Feb 28, 2013 at 02:29:11AM -0500, Mouse wrote: > > [...] > > Well, assuming rwlock(9) is considered a subset of mutex(9) for the > > purposes of that sentence, I then have to ask, what else is there? > > spl(9), the traditional way, specifically calls out that those routines > > work on only the CPU they're executed on (which is what I'd expect, > > given what they have traditionally done - but, I gather from the > > manpage, no longer do). > > > > This then leads me to wonder how a driver can _not_ be MPSAFE, since > > the old way doesn't/can't actually work and the new way is MPSAFE. > > A driver not marked MPSAFE will be entered (especially > its interrupt routine, but also from upper layers) with > kernel_lock held. This is what makes spl(9) still work. > In order to convert a driver using spl(9)-style calls, you have to replace > spl(9) calls with a mutex of the equivalent IPL level (a rwlock won't work > for this as it can't be used in interrupt routines, only thread context).
I want to complicate this idea of spl->mutex conversion a bit. I used to think that replacing spl calls by mutex calls would block the same interrupts that traditionally spl blocks. Then I realized that I'd been misled both by the "lore" surrounding spl->mutex conversion, and by reading (and re-reading) the manual: a mutex initialized with level `ipl' does NOT necessarily block interrupts. It will block them if it is a spin mutex (initialized with one of the hardware interrupt levels: IPL_VM, IPL_SCHED, IPL_HIGH), but it will not if it is an adaptive mutex (initialized with one of the software interrupt levels, IPL_SOFT*). So things are not 100% symmetrical in mutex land. Generally you're safe if both your interrupt handlers and your code running in the a "normal" thread context acquire & release the same mutex in critical sections. Dave -- David Young dyo...@pobox.com Urbana, IL (217) 721-9981