on 01/12/2011 20:49 John Baldwin said the following:
> On Thursday, December 01, 2011 11:59:10 am Andriy Gapon wrote:
>>
>> [cc list trimmed]
>>
>> on 21/11/2011 18:32 John Baldwin said the following:
>>> On Friday, November 18, 2011 4:59:32 pm Andriy Gapon wrote:
>>>> on 17/11/2011 23:38 John Baldwin said the following:
>>>>> On Thursday, November 17, 2011 4:35:07 pm John Baldwin wrote:
>>>>>> Hmmm, you could also make critical_exit() not perform deferred
>>>>>> preemptions
>>>>>> if SCHEDULER_STOPPED? That would fix the recursion and still let the
>>>>>> preemption "work" when resuming from the debugger?
>>
>>
>> Just to clarify, probably you are actually suggesting to not perform deferred
>> preemptions if kdb_active == TRUE. Because that's where we get the
>> recursion (via
>> kdb_switch).
>>
>> I think that if we get into the mi_switch in a state where !kdb_active &&
>> SCHEDULER_STOPPED(), then we probably should just - I don't know - panic
>> again?
>>
>> [the following is preserved for context]
>
> Hmmm. I'd be tempted to just ignore pending preemptions anytime
> SCHEDULER_STOPPED() is true. If it's stopped for a reason other than being
> in the debugger (e.g. panic), I'd rather make a best effort at getting a dump
> than panic again.
Yep, me too. It's just that I assumed that ending up at mi_switch in the panic
thread/context meant that something had gone very wrong already. But I am not
sure if this was a valid assumption.
Returning to critical_exit, what do you think about the following patch?
I guess that it could be committed independently of / before the
SCHEDULER_STOPPED thing.
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
kdb_switch
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;
thread_lock(td);
td->td_critnest--;
Would it make sense wrap kdb_active check with __predict_false?
--
Andriy Gapon
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
