Nicholas Piggin <[email protected]> writes: > On Thu, 23 Aug 2018 12:06:53 +0530 > Mahesh J Salgaonkar <[email protected]> wrote: >> From: Mahesh Salgaonkar <[email protected]> >> >> With the powerpc next commit e7e81847478 (powerpc/mce: Fix SLB rebolting >> during MCE recovery path.), the SLB error recovery is broken. The new >> change now does not add index value to RB[52-63] that selects the SLB >> entry while rebolting, instead it assumes that the shadow save area >> already have index embeded correctly in esid field. While all valid bolted >> save areas do contain index value set correctly, there is a case where >> 3rd (KSTACK_INDEX) entry for kernel stack does not embed index for NULL >> esid entry. This patch fixes that. >> >> Without this patch the SLB rebolt code overwrites the 1st entry of kernel >> linear mapping and causes SLB recovery to fail. >> >> Signed-off-by: Mahesh Salgaonkar <[email protected]> >> Signed-off-by: Nicholas Piggin <[email protected]> >> Reviewed-by: Nicholas Piggin <[email protected]> > > Changelog just needs a little more work, maybe this? > > > The commit e7e81847478 ("powerpc/64s: move machine check SLB flushing > to mm/slb.c") introduced a bug in reloading bolted SLB entries. Unused > bolted entries are stored with .esid=0 in the slb_shadow area, and > that value is now used directly as the RB input to slbmte, which means > the RB[52:63] index field is set to 0, which causes SLB entry 0 to be > cleared. > > Fix this by storing the index bits in the unused bolted entries, which > directs the slbmte to the right place. > > The SLB shadow area is also used by the hypervisor, but PAPR is okay > with that, from LoPAPR v1.1, 14.11.1.3 SLB Shadow Buffer: > > Note: SLB is filled sequentially starting at index 0 > from the shadow buffer ignoring the contents of > RB field bits 52-63 > > Fixes: e7e81847478 ("powerpc/64s: move machine check SLB flushing to > mm/slb.c")
Yep I'll take that, thanks. cheers
