> From: David Miller <da...@redhat.com> > 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 (mr...@linux.ee) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
