Re: [PATCH] powerpc/32s: Fix napping restore in data storage interrupt (DSI)

From: Christophe Leroy <christophe.leroy@csgroup.eu>
To: Finn Thain <fthain@linux-m68k.org>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	Paul Mackerras <paulus@samba.org>,
	Michael Ellerman <mpe@ellerman.id.au>,
	userm57@yahoo.com, linux-kernel@vger.kernel.org,
	linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH] powerpc/32s: Fix napping restore in data storage interrupt (DSI)
Date: Wed, 4 Aug 2021 08:07:29 +0200	[thread overview]
Message-ID: <b04a90a9-9d62-2192-f896-ea99be911604@csgroup.eu> (raw)
In-Reply-To: <ce20d16c-b0b2-94c-3e22-794d95c376b@linux-m68k.org>

Le 04/08/2021 à 06:04, Finn Thain a écrit :
> On Tue, 3 Aug 2021, Christophe Leroy wrote:
> 
>> When a DSI (Data Storage Interrupt) is taken while in NAP mode, r11
>> doesn't survive the call to power_save_ppc32_restore().
>>
>> So use r1 instead of r11 as they both contain the virtual stack pointer
>> at that point.
>>
>> Reported-by: Finn Thain <fthain@linux-m68k.org>
>> Fixes: 4c0104a83fc3 ("powerpc/32: Dismantle EXC_XFER_STD/LITE/TEMPLATE")
> 
> Regarding that 'Fixes' tag, this patch has not fixed the failure below,
> unfortunately. But there appears to be several bugs in play here. Can you
> tell us which failure mode is associated with the bug addressed by this
> patch?

This is unrelated to the failure below. This patch is related to the bisect you did that pointed to 
4c0104a83fc3 ("powerpc/32: Dismantle EXC_XFER_STD/LITE/TEMPLATE")

I think maybe the starting point should be to (manually) apply the patch on top of that commit in 
order to check that the bug to leaded to pointing that commit as 'first bad commit' is now gone.

The BUG below is likely something completely different.

And the other bug involving KUAP write is also something else to be investigated separately.

> 
> ------------[ cut here ]------------
> kernel BUG at arch/powerpc/kernel/interrupt.c:49!
> Oops: Exception in kernel mode, sig: 5 [#1]
> BE PAGE_SIZE=4K MMU=Hash SMP NR_CPUS=2 PowerMac
> Modules linked in:
> CPU: 0 PID: 1859 Comm: xfce4-session Not tainted 5.13.0-pmac-VMAP #10
> NIP:  c0011474 LR: c0011464 CTR: 00000000
> REGS: e2f75e40 TRAP: 0700   Not tainted  (5.13.0-pmac-VMAP)
> MSR:  00021032 <ME,IR,DR,RI>  CR: 2400446c  XER: 20000000
> 
> GPR00: c001604c e2f75f00 ca284a60 00000000 00000000 a5205eb0 00000008 00000020
> GPR08: ffffffc0 00000001 501200d9 ce030005 ca285010 00c1f778 00000000 00000000
> GPR16: 00945b20 009402f8 00000001 a6b87550 a51fd000 afb73220 a6b22c78 a6a6aecc
> GPR24: 00000000 ffffffc0 00000020 00000008 a5205eb0 00000000 e2f75f40 000000ae
> NIP [c0011474] system_call_exception+0x60/0x164
> LR [c0011464] system_call_exception+0x50/0x164
> Call Trace:
> [e2f75f00] [00009000] 0x9000 (unreliable)
> [e2f75f30] [c001604c] ret_from_syscall+0x0/0x28
> --- interrupt: c00 at 0xa69d6cb0
> NIP:  a69d6cb0 LR: a69d6c3c CTR: 00000000
> REGS: e2f75f40 TRAP: 0c00   Not tainted  (5.13.0-pmac-VMAP)
> MSR:  0000d032 <EE,PR,ME,IR,DR,RI>  CR: 2400446c  XER: 20000000
> 
> GPR00: 000000ae a5205de0 a5687ca0 00000000 00000000 a5205eb0 00000008 00000020
> GPR08: ffffffc0 401201ea 401200d9 ffffffff c158f230 00c1f778 00000000 00000000
> GPR16: 00945b20 009402f8 00000001 a6b87550 a51fd000 afb73220 a6b22c78 a6a6aecc
> GPR24: afb72fc8 00000000 00000001 a5205f30 afb733dc 00000000 a6b85ff4 a5205eb0
> NIP [a69d6cb0] 0xa69d6cb0
> LR [a69d6c3c] 0xa69d6c3c
> --- interrupt: c00
> Instruction dump:
> 7cdb3378 93810020 7cbc2b78 93a10024 7c9d2378 93e1002c 7d3f4b78 4800d629
> 817e0084 931e0088 69690002 5529fffe <0f090000> 69694000 552997fe 0f090000
> ---[ end trace c66c6c3c44806276 ]---
> 