[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <9e96b084-1914-f82e-5577-183bb7082d18@csgroup.eu>
Date: Fri, 12 Mar 2021 09:40:53 +0100
From: Christophe Leroy <christophe.leroy@...roup.eu>
To: Nicholas Piggin <npiggin@...il.com>,
Benjamin Herrenschmidt <benh@...nel.crashing.org>,
Michael Ellerman <mpe@...erman.id.au>,
Paul Mackerras <paulus@...ba.org>
Cc: linux-kernel@...r.kernel.org, linuxppc-dev@...ts.ozlabs.org
Subject: Re: [PATCH v2 02/43] powerpc/traps: Declare unrecoverable_exception()
as __noreturn
Le 10/03/2021 à 02:22, Nicholas Piggin a écrit :
> Excerpts from Christophe Leroy's message of March 9, 2021 10:09 pm:
>> unrecoverable_exception() is never expected to return, most callers
>> have an infiniteloop in case it returns.
>>
>> Ensure it really never returns by terminating it with a BUG(), and
>> declare it __no_return.
>>
>> It always GCC to really simplify functions calling it. In the exemple
>> below, it avoids the stack frame in the likely fast path and avoids
>> code duplication for the exit.
>>
>> With this patch:
>
> [snip]
>
> Nice.
>
>> diff --git a/arch/powerpc/kernel/traps.c b/arch/powerpc/kernel/traps.c
>> index a44a30b0688c..d5c9d9ddd186 100644
>> --- a/arch/powerpc/kernel/traps.c
>> +++ b/arch/powerpc/kernel/traps.c
>> @@ -2170,11 +2170,15 @@ DEFINE_INTERRUPT_HANDLER(SPEFloatingPointRoundException)
>> * in the MSR is 0. This indicates that SRR0/1 are live, and that
>> * we therefore lost state by taking this exception.
>> */
>> -void unrecoverable_exception(struct pt_regs *regs)
>> +void __noreturn unrecoverable_exception(struct pt_regs *regs)
>> {
>> pr_emerg("Unrecoverable exception %lx at %lx (msr=%lx)\n",
>> regs->trap, regs->nip, regs->msr);
>> die("Unrecoverable exception", regs, SIGABRT);
>> + /* die() should not return */
>> + WARN(true, "die() unexpectedly returned");
>> + for (;;)
>> + ;
>> }
>
> I don't think the WARN should be added because that will cause another
> interrupt after something is already badly wrong, so this might just
> make it harder to debug.
>
> For example if die() is falling through for some reason, we warn and
> cause a program check here, and that might also be unrecoverable so it
> might come through here and fall through again and warn again, etc.
>
> Putting the infinite loop is good enough I think (and better than there
> was previously).
Ok, dropped the WARN()
>
> Otherwise
>
> Reviewed-by: Nicholas Piggin <npiggin@...il.com>
>
> Thanks,
> Nick
>
Powered by blists - more mailing lists