Re: [PATCH] x86/tdx: Fix __noreturn build warning around __tdx_hypercall_failed()

From: Ingo Molnar
Date: Fri Sep 15 2023 - 08:27:00 EST



* Kai Huang <kai.huang@xxxxxxxxx> wrote:

> LKP reported below build warning:
>
> vmlinux.o: warning: objtool: __tdx_hypercall+0x128: __tdx_hypercall_failed() is missing a __noreturn annotation
>
> Turns out the __noreturn must be annotated to the function declaration
> but not the function body.
>
> Quoted from PeterZ:
>
> ---
> FWIW, the reason being that...
>
> The point of noreturn is that the caller should know to stop generating
> code. For that the declaration needs the attribute, because call sites
> typically do not have access to the function definition in C.
> ---
>
> Fix by moving __noreturn annotation from the __tdx_hypercall_failed()
> body to its declaration, which is in <asm/shared/tdx.h>.
>
> Note <asm/shared/tdx.h> is also included by TDX related assembly files.
> Include <linux/compiler_attributes.h> only in case of !__ASSEMBLY__
> otherwise compiling assembly file would trigger build error.
>
> Also, following the objtool documentation, add __tdx_hypercall_failed()
> to "tools/objtool/noreturns.h".
>
> Fixes: c641cfb5c157 ("x86/tdx: Make TDX_HYPERCALL asm similar to TDX_MODULE_CALL")
> Reported-by: kernel test robot <lkp@xxxxxxxxx>
> Closes: https://lore.kernel.org/oe-kbuild-all/202309140828.9RdmlH2Z-lkp@xxxxxxxxx/
> Signed-off-by: Kai Huang <kai.huang@xxxxxxxxx>
> ---
> arch/x86/coco/tdx/tdx.c | 2 +-
> arch/x86/include/asm/shared/tdx.h | 4 +++-
> tools/objtool/noreturns.h | 1 +
> 3 files changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/arch/x86/coco/tdx/tdx.c b/arch/x86/coco/tdx/tdx.c
> index 3e6dbd2199cf..4710d8dd700b 100644
> --- a/arch/x86/coco/tdx/tdx.c
> +++ b/arch/x86/coco/tdx/tdx.c
> @@ -38,7 +38,7 @@
> #define TDREPORT_SUBTYPE_0 0
>
> /* Called from __tdx_hypercall() for unrecoverable failure */
> -noinstr void __noreturn __tdx_hypercall_failed(void)
> +noinstr void __tdx_hypercall_failed(void)
> {

It's not a bad idea to document the __noreturn nature at the definition
site either, so I don't think we should remove it.

Thanks,

Ingo