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

[Ingo Molnar <mingo@kernel.org>]

* Kai Huang <kai.huang@intel.com> 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@intel.com>
> Closes: https://lore.kernel.org/oe-kbuild-all/202309140828.9RdmlH2Z-lkp@intel.com/
> Signed-off-by: Kai Huang <kai.huang@intel.com>
> ---
>  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