Date: Sat, 2 Oct 2010 00:41:07 -0700 (PDT) From: Don Lewis <truckman@FreeBSD.org> To: arch@FreeBSD.org Subject: "process slock" vs. "scrlock" lock order Message-ID: <201010020741.o927f7FJ056708@gw.catspoiler.org>
next in thread | raw e-mail | index | archive | help
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?
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201010020741.o927f7FJ056708>