2023-08-14 10:06:48

by Tiezhu Yang

[permalink] [raw]
Subject: [PATCH v3 1/3] MIPS: Remove noreturn attribute for nmi_exception_handler()

In the later patch, we will remove noreturn attribute for die(), in order
to make each patch can be built without errors and warnings, just remove
noreturn attribute for nmi_exception_handler() earlier because it calls
die(), otherwise there exists the following build error after the later
patch:

arch/mips/kernel/traps.c:2001:1: error: 'noreturn' function does return [-Werror]

Signed-off-by: Tiezhu Yang <[email protected]>
---
arch/mips/kernel/traps.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/mips/kernel/traps.c b/arch/mips/kernel/traps.c
index 246c6a6..7a34674 100644
--- a/arch/mips/kernel/traps.c
+++ b/arch/mips/kernel/traps.c
@@ -1986,7 +1986,7 @@ int register_nmi_notifier(struct notifier_block *nb)
return raw_notifier_chain_register(&nmi_chain, nb);
}

-void __noreturn nmi_exception_handler(struct pt_regs *regs)
+void nmi_exception_handler(struct pt_regs *regs)
{
char str[100];

--
2.1.0



2023-08-18 05:16:30

by Maciej W. Rozycki

[permalink] [raw]
Subject: Re: [PATCH v3 1/3] MIPS: Remove noreturn attribute for nmi_exception_handler()

On Mon, 14 Aug 2023, Tiezhu Yang wrote:

> In the later patch, we will remove noreturn attribute for die(), in order
> to make each patch can be built without errors and warnings, just remove
> noreturn attribute for nmi_exception_handler() earlier because it calls
> die(), otherwise there exists the following build error after the later
> patch:

I find the wording a bit odd here, but you'll have to rewrite the change
description for the update requested below, so let's defer any style fixes
to v4.

> arch/mips/kernel/traps.c:2001:1: error: 'noreturn' function does return [-Werror]

Now that I've looked into it in detail, this change is incomplete and
will make the kernel go astray if `nmi_exception_handler' actually ever
does return. See code in arch/mips/kernel/genex.S, which calls this
function and doesn't expect it to return. It has to be fixed before 2/3
can be considered. I wonder how you didn't catch it: you did check how
this code is used, didn't you?

Before submitting an updated version can you actually arrange for the
NOTIFY_STOP condition to happen in your lab and verify it is handled as
expected? And what was the motivation for this code update, just a
hypothetical scenario?

Maciej