Dale Farnsworth writes: > There's a race between a critical exception and the normal exception > entry path. If a normal exception occurs in user mode and then a > critical exception occurs before the normal exception handler has set > r1 to the kernel stack area, we end up with r1 containing the user sp, > though the critical exception occurred in kernel mode.
That's a separate problem from what we were discussing, which is why program_check_exception is entered with interrupts disabled. > I haven't yet come up with a way to detect this case and reliably use > the kernel stack on a critical exception. One way to solve this is to put the kernel stack pointer in some SPRGn when exiting to usermode, and on critical exceptions, use that SPRGn for the kernel stack if it is non-zero. In the exception entry path (for both normal and critical exceptions) put 0 in it once r1 has been set up with a valid kernel stack pointer. This also works if you have to call firmware such as RTAS which runs in kernel mode but may put arbitrary values in r1. Paul.
