Michal Suchánek <msucha...@suse.de> writes: > On Tue, 3 Jul 2018 08:08:14 +1000 > Nicholas Piggin <npig...@gmail.com> wrote: >> On Mon, 02 Jul 2018 11:17:06 +0530 >> Mahesh J Salgaonkar <mah...@linux.vnet.ibm.com> wrote: >> > From: Mahesh Salgaonkar <mah...@linux.vnet.ibm.com> >> > >> > On pseries, as of today system crashes if we get a machine check >> > exceptions due to SLB errors. These are soft errors and can be >> > fixed by flushing the SLBs so the kernel can continue to function >> > instead of system crash. We do this in real mode before turning on >> > MMU. Otherwise we would run into nested machine checks. This patch >> > now fetches the rtas error log in real mode and flushes the SLBs on >> > SLB errors. >> > >> > Signed-off-by: Mahesh Salgaonkar <mah...@linux.vnet.ibm.com> >> > --- >> > arch/powerpc/include/asm/book3s/64/mmu-hash.h | 1 >> > arch/powerpc/include/asm/machdep.h | 1 >> > arch/powerpc/kernel/exceptions-64s.S | 42 >> > +++++++++++++++++++++ arch/powerpc/kernel/mce.c >> > | 16 +++++++- arch/powerpc/mm/slb.c | >> > 6 +++ arch/powerpc/platforms/powernv/opal.c | 1 >> > arch/powerpc/platforms/pseries/pseries.h | 1 >> > arch/powerpc/platforms/pseries/ras.c | 51 >> > +++++++++++++++++++++++++ >> > arch/powerpc/platforms/pseries/setup.c | 1 9 files >> > changed, 116 insertions(+), 4 deletions(-) >> >> >> > +TRAMP_REAL_BEGIN(machine_check_pSeries_early) >> > +BEGIN_FTR_SECTION >> > + EXCEPTION_PROLOG_1(PACA_EXMC, NOTEST, 0x200) >> > + mr r10,r1 /* Save r1 */ >> > + ld r1,PACAMCEMERGSP(r13) /* Use MC emergency >> > stack */ >> > + subi r1,r1,INT_FRAME_SIZE /* alloc stack >> > frame */ >> > + mfspr r11,SPRN_SRR0 /* Save SRR0 */ >> > + mfspr r12,SPRN_SRR1 /* Save SRR1 */ >> > + EXCEPTION_PROLOG_COMMON_1() >> > + EXCEPTION_PROLOG_COMMON_2(PACA_EXMC) >> > + EXCEPTION_PROLOG_COMMON_3(0x200) >> > + addi r3,r1,STACK_FRAME_OVERHEAD >> > + BRANCH_LINK_TO_FAR(machine_check_early) /* Function call >> > ABI */ >> >> Is there any reason you can't use the existing >> machine_check_powernv_early code to do all this? > > Code sharing is nice but if we envision this going to stable kernels > butchering the existing handler is going to be a nightmare. The code is > quite a bit different between kernel versions.
I'm not sure if we'll send it to stable kernels. But we obviously will back port it to some distros :) So if sharing the code is a significant impediment to that, then I'm happy if we don't share code initially. That could be done as a follow-up to this series. cheers
