"process slock" vs. "scrlock" lock order

Don Lewis truckman at FreeBSD.org
Sat Oct 2 08:14:07 UTC 2010


The hard coded lock order list in subr_witness.c has "scrlock" listed
before "process slock".  This causes a lock order reversal when
calcru1(), which requires "process slock" to be held, calls printf() to
report unexpected runtime problems.  The call to printf() eventually
gets into the console code which locks "scrlock".  This normally isn't
noticed because both of these are spin locks, and hardly anyone uses
WITNESS without disabling the checking of spinlocks with
WITNESS_SKIPSPIN.  If spin lock checking is not disabled, the result is
a silent reset because witness catches the LOR, which recurses into
printf(), which ends up causing a panic in cnputs().

One obvious fix would be to move "scrlock" to a later spot in the list,
but I suspect the same problem could occur with the "sio" or "uart"
locks if a serial console is being used.  It might not be possible to
fix them the same way because there might be cases where they are in the
input path and get locked before "process slock" or other spin locks
that can be held when calling printf().

Another fix for this particular case would be to rearrange the code in
calcru1() so that the calls to printf() occur after ruxp->rux_* are
updated and where I assume it would be safe to temporarily drop "process
slock" for the duration of the printf() calls.

Thoughts?



More information about the freebsd-arch mailing list