Date: Sat, 21 Jan 2012 16:37:11 +0200 From: Andriy Gapon <avg@FreeBSD.org> To: current@FreeBSD.org Cc: Gleb Smirnoff <glebius@FreeBSD.org> Subject: locks under printf(9) and WITNESS [Was: new panic in cpu_reset() with WITNESS] Message-ID: <4F1ACD97.5080506@FreeBSD.org> In-Reply-To: <4F1ABFF3.9090305@FreeBSD.org> References: <20120117110242.GD12760@glebius.int.ru> <20120120154158.GD16676@FreeBSD.org> <4F1ABFF3.9090305@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
BTW, we have a quite strange situation with spin locks in console output path. cnputs_mtx is marked as MTX_NOWITNESS, supposedly because cnputs (printf) can be called in any locking context (even during normal operation). But there are a number of console-specific locks (scrlock, uart_hwmtx, "syscons video lock") which are acquired under cnputs_mtx, but which are *not* marked as MTX_NOWITNESS. More, they are specified in the witness order_lists as if we certainly know a correct order for them. I think that the msgbuf mutex also deserves mentioning in this context. I think that all of these spin locks should be marked as MTX_NOWITNESS (as long as they stay normal spinlocks), because printf(9) should be usable wherever I stick it in the code. P.S. The above only matters for WITNESS and !WITNESS_SKIPSPIN and I am not sure if this combination really matters. -- Andriy Gapon
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4F1ACD97.5080506>