Re: wrong SP restored after DBE exception

[Ralf Baechle <ralf@linux-mips.org>]

On Thu, Sep 28, 2006 at 02:56:29PM +0100, Maciej W. Rozycki wrote:

> > If we take a DBE exception in this code we're in trouble and I've seen
> > systems delivering DBEs highly asynchronously.  Afar the Broadcom SOCs
> > fall into that class.
> > 
> > So the interesting part is if we take a data bus exception between
> > the stack pointer adjustment and and before EXL is cleared.  We're taking
> > a nested exception so c0_epc and c0_cause.bd will not be updated.  So
> > when the bus error handler will save the $sp value it saw on entry but
> > will return to the EPC of the first exception, that is only one stack
> > frame will be popped.  Whops ...
> 
>  It looks like a design issue -- further asynchronous bus error exceptions 
> should be blocked till one currenly being handled has been acked.  In fact 
> if they are asynchronous, then it really makes no sense to use the 
> exception and a general interrupt should be used instead -- the whole 
> point of using an exception here is the ability to stop a data corrupting 
> transaction, as unlike an interropt, an exception can be precise.

I would suggest to disable interrupts around accesses that potencially
could result in DB exceptions and just to make sure he is not getting
trapped by a non-blocking load by making some use of any value read
from the device.  Writes could be posted depending on bus type.  So
having a read from the same device would force the write to complete.

  Ralf