> -----Original Message----- > From: Marcelo Tosatti [mailto:marcelo.tosatti at cyclades.com] > On Sat, Apr 09, 2005 at 09:03:54PM +0200, Joakim Tjernlund wrote: > > > > > > On Apr 8, 2005, at 7:07 AM, Marcelo Tosatti wrote:
[SNIP] > > I still think this can be resolved in fault.c. Replace > > andis. r11, r10, 0x0200 /* If set, indicates store op */ > > beq 2f > > in the DTLB Error handler with > > andis. r11, r10, 0x4800 /* If set, indicates invalid pte or > > protection violation */ > > bne 2f > > Why does the current code jump to page fault handler in case of store > operation? It doesn't. It jumps if some other bit is set as well. In your dcbst case it seems like invalid is set too. I hope that will be enough to work something out in fault.c. > > Out of curiosity, aren't there any other valid bit combinations for DSISR > other > than 0x4800 which should allow a fastpath DataTLBError ? Don't know, hopefully Dan knows. > > I can't find DSISR settings in MPC860UM.pdf neither paper manual. AFAICS it > always refer to the PEM when talking about DSISR bit assignments. > > I can't find section "7-15" as you mentioned in the other email. It is page 7-15 and I think(not having the manual handy) that chapter 7 describes the different exceptions including the DTLB Error. > > > In fault.c you can check if both store and invalid is set simultaneously. > > If it is, clear > > the store flag and continue as usual. > > One point is that by changing the in-kernel dcbst implementation userspace is > still vulnerable to the problem. > > Now fixing the exception handler to deal with such boggosity as Joakim > proposes is > complete - it handles userspace dcbst callers. Yes, ldso uses dcbst and icbi. Currently it works fine because a normal store has been performed before dcbst/icbi is executed. Jocke
