> From: David Miller <davem@xxxxxxxxxx> > Date: Thu, 16 Oct 2014 16:20:01 -0400 (EDT) > > > So I'm going to audit all the code paths to make sure we don't put garbage > > into the fault_code value. > > There are two code paths where we can put garbage into the fault_code > value. And for the dtlb_prot.S case, the value we put in there is > TLB_TAG_ACCESS which is 0x30, which include bit 0x20 which is that > FAULT_CODE_BAD_RA indication which is erroneously triggering. > > The other path is via hugepage TLB misses, for the situation where > we haven't allocated the huge TSB for the thread yet. That might > explain some other longer-term problems we've had. > > I'm about to test the following fix: Thank you - it seems to work fine for me on E3500 on top of 3.17.0-07551-g052db7e + slab alignment fix. However, on top of mainline HEAD 3.17.0-09670-g0429fbc it explodes with scheduler BUG - just reported to LKML + sched maintainers. -- Meelis Roos (mroos@xxxxxxxx) -- To unsubscribe from this list: send the line "unsubscribe sparclinux" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
