Date: Mon, 05 Sep 2011 14:26:04 +0300 From: Andriy Gapon <avg@FreeBSD.org> To: freebsd-arch@FreeBSD.org Subject: SCHEDULER_STOPPED vs kdb_active Message-ID: <4E64B1CC.9070205@FreeBSD.org>
next in thread | raw e-mail | index | archive | help
My simple question is whether kdb_active should be included as another indicator into SCHEDULER_STOPPED? I assume that kdb_active == true is visible only to the debugger code and never to the debugged code. I understand that there is some code that can be executed in both roles, but I am specifically asking about the roles, not the physical code. So, is this true? Assuming that the above is true, it doesn't make sense to not by-pass locking if the debugger infrastructure executes some common code. For example I don't understand why the kdb_active checks in kern_mutex.c are what they are. I think that kdb_active means that the currently running code is the only code that can make forward progress in the system. If we stumble upon a locked spinlock, then it doesn't make any sense to spin on it waiting for Godot. Similarly, I think that mtx_asser() should be a NOP if kdb_active. What important things/scenarios do I overlook? -- Andriy Gapon
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4E64B1CC.9070205>