On 12/1/11 4:42 PM, Andriy Gapon wrote:
on 01/12/2011 22:53 John Baldwin said the following:
On Thursday, December 01, 2011 3:42:24 pm Andriy Gapon wrote:
Returning to critical_exit, what do you think about the following patch?
I guess that it could be committed independently of / before the

commit ee3d1a04985e86911a68d854439ae8c5429b7bd5
Author: Andriy Gapon<a...@icyb.net.ua>
Date:   Thu Dec 1 18:53:36 2011 +0200

     critical_exit: ignore td_owepreempt if kdb_active

     calling mi_switch in such a context result in a recursion via

diff --git a/sys/kern/kern_switch.c b/sys/kern/kern_switch.c
index 93cbf7b..885dc22 100644
--- a/sys/kern/kern_switch.c
+++ b/sys/kern/kern_switch.c
@@ -200,7 +200,7 @@ critical_exit(void)

        if (td->td_critnest == 1) {
                td->td_critnest = 0;
-               if (td->td_owepreempt) {
+               if (td->td_owepreempt&&  !kdb_active) {
                        td->td_critnest = 1;

I think this is fine, but I'd probably change this to SCHEDULER_STOPPED()
in the SCHEDULER_STOPPED() patch.

I don't understand why...  What if kdb is entered for some other reason, not
because of panic?  In that case SCHEDULER_STOPPED() would be false, but it is
still possible to find a way into mi_switch.

The SCHEDULER_STOPPED patch adds this:
@@ -428,6 +428,8 @@ mi_switch(int flags, struct thread *newtd)
         if (kdb_active)
+       if (SCHEDULER_STOPPED())
+               return;
         if (flags&  SW_VOL) {
                 td->td_swvoltick = ticks;

Ah, ok (I had thought SCHEDULER_STOPPED was going to always be true when kdb was active). But I think these two changes should cover critical_exit() ok.

John Baldwin
freebsd-current@freebsd.org mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Reply via email to