[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LRH.2.11.1410171410210.25429@adalberg.ut.ee>
Date: Fri, 17 Oct 2014 14:12:09 +0300 (EEST)
From: Meelis Roos <mroos@...ux.ee>
To: David Miller <davem@...emloft.net>
cc: iamjoonsoo.kim@....com, linux-kernel@...r.kernel.org, cl@...ux.com,
penberg@...nel.org, rientjes@...gle.com, akpm@...ux-foundation.org,
linux-mm@...ck.org, sparclinux@...r.kernel.org
Subject: Re: unaligned accesses in SLAB etc.
> From: David Miller <davem@...hat.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 (mroos@...ux.ee)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists