From: "Roger Pau Monné" <roger.pau@citrix.com>
To: victorm.lira@amd.com
Cc: xen-devel@lists.xenproject.org,
Nicola Vetrini <nicola.vetrini@bugseng.com>,
Andrew Cooper <andrew.cooper3@citrix.com>,
Anthony PERARD <anthony.perard@vates.tech>,
Michal Orzel <michal.orzel@amd.com>,
Jan Beulich <jbeulich@suse.com>, Julien Grall <julien@xen.org>,
Stefano Stabellini <sstabellini@kernel.org>,
Federico Serafini <federico.serafini@bugseng.com>,
Bertrand Marquis <bertrand.marquis@arm.com>
Subject: Re: [PATCH v2 3/3] xen/x86: add missing noreturn attributes
Date: Wed, 18 Jun 2025 17:18:13 +0200 [thread overview]
Message-ID: <aFLYtSgt5b4lQwgv@macbook.local> (raw)
In-Reply-To: <20250606212712.1901838-3-victorm.lira@amd.com>
On Fri, Jun 06, 2025 at 02:27:09PM -0700, victorm.lira@amd.com wrote:
> From: Nicola Vetrini <nicola.vetrini@bugseng.com>
>
> The marked functions never return to their caller, but lack the
> `noreturn' attribute.
>
> Functions that never return should be declared with a `noreturn'
> attribute.
>
> The lack of `noreturn' causes a violation of MISRA C Rule 17.11 (not
> currently accepted in Xen), and also Rule 2.1: "A project shall not
> contain unreachable code". Depending on the compiler used and the
> compiler optimization used, the lack of `noreturn' might lead to the
> presence of unreachable code.
>
> No functional change.
>
> Signed-off-by: Nicola Vetrini <nicola.vetrini@bugseng.com>
> Signed-off-by: Victor Lira <victorm.lira@amd.com>
Acked-by: Roger Pau Monné <roger.pau@citrix.com>
One question below.
> ---
> Changes in v2:
> - improved commit message
> ---
> Cc: Andrew Cooper <andrew.cooper3@citrix.com>
> Cc: Anthony PERARD <anthony.perard@vates.tech>
> Cc: Michal Orzel <michal.orzel@amd.com>
> Cc: Jan Beulich <jbeulich@suse.com>
> Cc: Julien Grall <julien@xen.org>
> Cc: Roger Pau Monné <roger.pau@citrix.com>
> Cc: Stefano Stabellini <sstabellini@kernel.org>
> Cc: Nicola Vetrini <nicola.vetrini@bugseng.com>
> Cc: Federico Serafini <federico.serafini@bugseng.com>
> Cc: Bertrand Marquis <bertrand.marquis@arm.com>
> ---
> xen/arch/x86/cpu/mcheck/mce.c | 3 ++-
> xen/arch/x86/efi/efi-boot.h | 2 +-
> xen/arch/x86/smp.c | 2 +-
> xen/arch/x86/traps.c | 2 +-
> xen/arch/x86/x86_64/traps.c | 2 +-
> 5 files changed, 6 insertions(+), 5 deletions(-)
>
> diff --git a/xen/arch/x86/cpu/mcheck/mce.c b/xen/arch/x86/cpu/mcheck/mce.c
> index 1c348e557d..79214ce56b 100644
> --- a/xen/arch/x86/cpu/mcheck/mce.c
> +++ b/xen/arch/x86/cpu/mcheck/mce.c
> @@ -79,7 +79,8 @@ static int __init cf_check mce_set_verbosity(const char *str)
> custom_param("mce_verbosity", mce_set_verbosity);
>
> /* Handle unconfigured int18 (should never happen) */
> -static void cf_check unexpected_machine_check(const struct cpu_user_regs *regs)
> +static void noreturn cf_check
> +unexpected_machine_check(const struct cpu_user_regs *regs)
> {
> console_force_unlock();
> printk("Unexpected Machine Check Exception\n");
> diff --git a/xen/arch/x86/efi/efi-boot.h b/xen/arch/x86/efi/efi-boot.h
> index 0ecf4ca53f..0194720003 100644
> --- a/xen/arch/x86/efi/efi-boot.h
> +++ b/xen/arch/x86/efi/efi-boot.h
> @@ -769,7 +769,7 @@ static void __init efi_arch_blexit(void)
> efi_bs->FreePages(ucode.addr, PFN_UP(ucode.size));
> }
>
> -static void __init efi_arch_halt(void)
> +static void noreturn __init efi_arch_halt(void)
> {
> local_irq_disable();
> for ( ; ; )
> diff --git a/xen/arch/x86/smp.c b/xen/arch/x86/smp.c
> index 516dab5528..7936294f5f 100644
> --- a/xen/arch/x86/smp.c
> +++ b/xen/arch/x86/smp.c
> @@ -343,7 +343,7 @@ void __stop_this_cpu(void)
> cpumask_clear_cpu(smp_processor_id(), &cpu_online_map);
> }
>
> -static void cf_check stop_this_cpu(void *dummy)
> +static void noreturn cf_check stop_this_cpu(void *dummy)
> {
> const bool *stop_aps = dummy;
>
> diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c
> index 092c7e4197..34dc077cad 100644
> --- a/xen/arch/x86/traps.c
> +++ b/xen/arch/x86/traps.c
> @@ -805,7 +805,7 @@ void fatal_trap(const struct cpu_user_regs *regs, bool show_remote)
> (regs->eflags & X86_EFLAGS_IF) ? "" : " IN INTERRUPT CONTEXT");
> }
>
> -void asmlinkage do_unhandled_trap(struct cpu_user_regs *regs)
> +void asmlinkage noreturn do_unhandled_trap(struct cpu_user_regs *regs)
> {
> fatal_trap(regs, false);
> }
> diff --git a/xen/arch/x86/x86_64/traps.c b/xen/arch/x86/x86_64/traps.c
> index c77f304bb0..8460a4a1ae 100644
> --- a/xen/arch/x86/x86_64/traps.c
> +++ b/xen/arch/x86/x86_64/traps.c
> @@ -293,7 +293,7 @@ void show_page_walk(unsigned long addr)
> l1_table_offset(addr), l1e_get_intpte(l1e), pfn);
> }
>
> -void asmlinkage do_double_fault(struct cpu_user_regs *regs)
> +void asmlinkage noreturn do_double_fault(struct cpu_user_regs *regs)
Does noreturn matter for functions called from assembly (asmlinkage
ones)? In that case the hint is not useful for code generation, since
it's hand written assembly already? (it's arguably useful for the
developer writing the code)
Might be worth mentioning in the commit message if the above is
accurate. For example by adding to the commit message: "noreturn is
not relevant for functions called from assembly, but can be used as a
hint for the developers writing the code".
Thanks, Roger.
next prev parent reply other threads:[~2025-06-18 15:18 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-06 21:27 [PATCH v2 1/3] xen/keyhandler: add missing noreturn attribute victorm.lira
2025-06-06 21:27 ` [PATCH v2 2/3] xen/arm: add missing noreturn attributes victorm.lira
2025-06-06 21:27 ` [PATCH v2 3/3] xen/x86: " victorm.lira
2025-06-18 0:48 ` Stefano Stabellini
2025-06-18 15:18 ` Roger Pau Monné [this message]
2025-06-18 16:16 ` Nicola Vetrini
2025-06-18 17:25 ` Roger Pau Monné
2025-06-20 6:16 ` Jan Beulich
2025-06-18 0:45 ` [PATCH v2 2/3] xen/arm: " Stefano Stabellini
2025-06-10 8:35 ` [PATCH v2 1/3] xen/keyhandler: add missing noreturn attribute Jan Beulich
2025-06-18 0:41 ` Stefano Stabellini
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aFLYtSgt5b4lQwgv@macbook.local \
--to=roger.pau@citrix.com \
--cc=andrew.cooper3@citrix.com \
--cc=anthony.perard@vates.tech \
--cc=bertrand.marquis@arm.com \
--cc=federico.serafini@bugseng.com \
--cc=jbeulich@suse.com \
--cc=julien@xen.org \
--cc=michal.orzel@amd.com \
--cc=nicola.vetrini@bugseng.com \
--cc=sstabellini@kernel.org \
--cc=victorm.lira@amd.com \
--cc=xen-devel@lists.xenproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.