svn commit: r222060 - in user/avg/xcpu/sys: kern sys

[Andriy Gapon]

on 26/05/2011 19:18 mdf at FreeBSD.org said the following:
> On Thu, May 26, 2011 at 9:05 AM, Andriy Gapon <avg at freebsd.org> wrote:
>> on 26/05/2011 18:46 mdf at FreeBSD.org said the following:
>>> A per-thread flag is needed as long as other CPUs can be running or
>>> even just the scheduler on the remaining CPU.  So I would thing that
>>> flag needs to be checked until the system has been massaged to the
>>> state you describe above.
>>
>> I am not sure that I understand your reasoning if you mean that the flag needs to
>> be checked in TD_IS_INPANIC.  That is, right now there is no TD_IS_INPANIC and
>> things work after panic to a certain degree.  I do not intend to improve that
>> degree and just want to keep an option to revert to the current state of matters.
>> When TD_IS_INPANIC is introduced and stop_cpus_on_panic==1, then there will be
>> only one thread left running after panic, that will be the thread that called
>> panic, checking TDF_INPANIC just doesn't add anything.
> 
> Won't the scheduler still run even if other CPUs are halted?  Is there
> any intent to prevent switching to another thread?  (I suppose this
> could be achieved by setting td_critnest++ and wouldn't require a
> flag).
> 
> It's possible I misunderstood your email so my response may have been
> non-sensical.

No, no, it does make sense.
I haven't mentioned this, but yes, new world order with stop_cpus_on_panic==1
implies disabling interrupts for a panic thread.  I also took it to mean that
there will not be any thread switches, but perhaps I am mistaken here...

In any case my intention is to ensure that only the panic thread runs.

-- 
Andriy Gapon