[PATCH] ppc32: handle Book E debug exceptions on kernel stack

[Dale Farnsworth]

On Fri, Feb 24, 2006 at 10:49:45AM +1100, David Gibson wrote:
> On Wed, Feb 22, 2006 at 10:19:54PM -0600, Kumar Gala wrote:
> > On Tue, 14 Feb 2006, Dale Farnsworth wrote:
> > 
> > > From: Dale Farnsworth <dale at farnsworth.org>
> > > 
> > > On PPC Book E processsors, we currently handle debug
> > > exceptions on the critical exception stack (debug stack
> > > for E200).  This causes problems with the kgdb single
> > > step handler, which calls smp_processor_id() and spin_lock(),
> > > which reference current_thread_info(), which only works when
> > > we are on the kernel stack.
> > > 
> > > We address this by switching to the kernel stack early while
> > > handling debug exceptions.  Note that the entry values of r10
> > > and r11 are still saved on the critical exception (or debug) stack.
> > > 
> > > Signed-off-by: Dale Farnsworth <dale at farnsworth.org>
> > > 
> > 
> > Paul,
> > 
> > We were wondering if you or David remember why a specific critical
> > exception stack was added in the 40x port from 2.4 to 2.6?
> 
> I don't, in any detail.  But did it have to do with a possible race
> with a critical exception in just the wrong part of the normal
> exception exit path.  ISTR BenH was worried about something in that
> area.

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.

I haven't yet come up with a way to detect this case and reliably use
the kernel stack on a critical exception.

-Dale