Keith Owens wrote: > > On Thu, 16 May 2002 20:34:07 -0400, > Jim Houston <[EMAIL PROTECTED]> wrote: > >The attached patch is an update of my earlier patch > >to fix smp problems in kdb. I started with Ethan > >Solomita's patch, but I have change a lot of code > >since then. I have been exchanging private email with > >Ethan over the last week, and he has helped find some > >of my bugs. Thanks again. There are always more bugs, > >but I think this patch has reached the useful stage. > > I finally got time to spend on kdb, my apologies for not answering > these patches sooner. > > Jim, Ethan, is this a common patch, or do you still have differences of > approach? > > >The changes are: > > > > - Splitting up the kdb_state variable to > > decouple data used for inter-processor > > synchronization from local flags. > > Good idea. > > > - Avoid having an extra layer of nesting > > if a processor is already in kdb when the > > kdb inter-processor interrupt is delivered. > > I agree with the aim but am a bit unhappy with putting the code in > entry.S. Patching the assembler closes the window between int3 and NMI > to a few instructions, at the cost of extra asm. Moving the kdb_in_kdb > setting to do_int3 will use C instead of asm. It is a trade off, a > slightly larger window for easier to maintain code.
Hi Keith, Ehtan The thought behind the entry.S change was to close the window completely. I believe the combination of setting kdb_in_kdb as early as possible and also doing the eip range check in kdba_check_in_kdb() accomplishes this. Another solution I considered was to do a stack walk back from kdb_ipi to see if it had interrupted the int3 entry. I also wondered about changing the kdb inter-processor interrupt to a normal interrupt and changing the breakpoint gate setup to mask the interrupts. On other architectures this may be the prefered solution. After considering these alternatives, the few lines in entry.S didn't seem that painful. I mentioned in earlier email that this fix also avoids the problem described in the comments before kdba_db_trap(). This is a panic which may happen if the user clears an interrupt which has not been processed yet because the kdb inter-processor interrupt has preempted the breakpoint processing. I willing to put more work into this patch and help get it working on the other platforms. Jim Houston - Concurrent Computer Corp.
