[linux-next:master 10163/12085] arch/arm64/kvm/hyp/nvhe/psci-relay.c:174:28: warning: no previous prototype for function 'kvm_host_psci_cpu_entry'

[kernel test robot]

tree: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
head: 2f1d5c77f13fe64497c2e2601605f7d7ec4da9b1
commit: cdf367192766ad11a03e8d5098556be43b8eb6b0 [10163/12085] KVM: arm64: Intercept host's CPU_ON SMCs
config: arm64-randconfig-r032-20201209 (attached as .config)
compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project 1968804ac726e7674d5de22bc2204b45857da344)
reproduce (this is a W=1 build):
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# install arm64 cross compiling tool for clang build
# apt-get install binutils-aarch64-linux-gnu
# https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=cdf367192766ad11a03e8d5098556be43b8eb6b0
git remote add linux-next https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
git fetch --no-tags linux-next master
git checkout cdf367192766ad11a03e8d5098556be43b8eb6b0
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=arm64

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <l...@intel.com>

All warnings (new ones prefixed by >>):

>> arch/arm64/kvm/hyp/nvhe/psci-relay.c:174:28: warning: no previous prototype for function 'kvm_host_psci_cpu_entry' [-Wmissing-prototypes]
asmlinkage void __noreturn kvm_host_psci_cpu_entry(bool is_cpu_on)
^
arch/arm64/kvm/hyp/nvhe/psci-relay.c:174:12: note: declare 'static' if the function is not intended to be used outside of this translation unit
asmlinkage void __noreturn kvm_host_psci_cpu_entry(bool is_cpu_on)
^
static
1 warning generated.

vim +/kvm_host_psci_cpu_entry +174 arch/arm64/kvm/hyp/nvhe/psci-relay.c

173
> 174 asmlinkage void __noreturn kvm_host_psci_cpu_entry(bool is_cpu_on)
175 {
176 struct psci_boot_args *boot_args;
177 struct kvm_cpu_context *host_ctxt;
178
179 host_ctxt = &this_cpu_ptr(hyp_symbol_addr(kvm_host_data))->host_ctxt;
180 boot_args = this_cpu_ptr(hyp_symbol_addr(cpu_on_args));
181
182 cpu_reg(host_ctxt, 0) = boot_args->r0;
183 write_sysreg_el2(boot_args->pc, SYS_ELR);
184 release_boot_args(boot_args);
185
186 __host_enter(host_ctxt);
187 }
188

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuil...@lists.01.org

[Marc Zyngier]

I wish someone would fix these reports and weed out these false
positive.

The function is annotated as asmlinkage, meaning it is called from some
assembly code. Not amount of prototyping is going to help the assembler,
and making it static is just going to break the build.

Thanks,

M.

>
> vim +/kvm_host_psci_cpu_entry +174 arch/arm64/kvm/hyp/nvhe/psci-relay.c
>
> 173
> > 174 asmlinkage void __noreturn kvm_host_psci_cpu_entry(bool
> is_cpu_on)
> 175 {
> 176 struct psci_boot_args *boot_args;
> 177 struct kvm_cpu_context *host_ctxt;
> 178
> 179 host_ctxt =
> &this_cpu_ptr(hyp_symbol_addr(kvm_host_data))->host_ctxt;
> 180 boot_args = this_cpu_ptr(hyp_symbol_addr(cpu_on_args));
> 181
> 182 cpu_reg(host_ctxt, 0) = boot_args->r0;
> 183 write_sysreg_el2(boot_args->pc, SYS_ELR);
> 184 release_boot_args(boot_args);
> 185
> 186 __host_enter(host_ctxt);
> 187 }
> 188
>
> ---
> 0-DAY CI Kernel Test Service, Intel Corporation
> https://lists.01.org/hyperkitty/list/kbuil...@lists.01.org

--
Jazz is not dead. It just smells funny...

[Nick Desaulniers]

While it's not great, my recommendation would be to provide a
declaration within the same source file. The warning is generally
about defining a function with extern linkage without having
previously declared a prototype, which can be dangerous when there's
other callers in other translation units as they would have to match
the prototype without any compiler checks. The compiler can't know
when looking in isolation at one translation unit that the only
callers are assembler.

See for example stpcpy in lib/string.c:
290 char *stpcpy(char *__restrict__ dest, const char *__restrict__
src);
291 char *stpcpy(char *__restrict__ dest, const char *__restrict__
src)
292 {
...

It has extern linkage but we don't really want people to call it, so
the prototype is provided within the TU to shut up
-Wmissing-prototypes. I'd argue we should do the same thing to fix
-Wmissing-prototypes for functions who are only called from assembler.

You might think "that's stupid" and I wouldn't disagree, but that's
one of the ways to resolve -Wmissing-prototypes:
1. use static linkage if no callers exist outside of the TU (does not
apply here, we have external callers), or
2. provide a declaration in a header so other C callers don't mess up
the prototype (does not apply here, we don't have external C callers),
or
3. provide a declaration in the same TU
(4. don't do W=1 builds. :P)

While it may be painful/weird for this case, making this TU
-Wmissing-prototypes clean allows folks to tackle the above 3 cases
throughout the tree.

> --
> You received this message because you are subscribed to the Google Groups "Clang Built Linux" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to clang-built-li...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/clang-built-linux/8d7aab68fd0d0a5d3ee1e99088e9a68e%40kernel.org.



--
Thanks,
~Nick Desaulniers