2:10 a.m.
On Tue, Feb 09, 2021 at 07:52:17PM +0000, Wei Liu wrote:
On Wed, Feb 10, 2021 at 01:40:32AM +0800, kernel test robot wrote:
> tree: https://git.kernel.org/pub/scm/linux/kernel/git/hyperv/linux.git
hyperv-next
> head: 9c9e1c68259d6cf8a348289fd13ed8f320c0d662
> commit: df3ae25f31b1f0ed6560c207a975abb2d4f87722 [22/32] x86/hyperv: extract
partition ID from Microsoft Hypervisor if necessary
> config: x86_64-randconfig-s022-20210209 (attached as .config)
> compiler: gcc-9 (Debian 9.3.0-15) 9.3.0
> reproduce:
> # apt-get install sparse
> # sparse version: v0.6.3-215-g0fb77bb6-dirty
> #
https://git.kernel.org/pub/scm/linux/kernel/git/hyperv/linux.git/commit/?...
> git remote add hyperv-linux
https://git.kernel.org/pub/scm/linux/kernel/git/hyperv/linux.git
> git fetch --no-tags hyperv-linux hyperv-next
> git checkout df3ae25f31b1f0ed6560c207a975abb2d4f87722
> # save the attached .config to linux build tree
> make W=1 C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=x86_64
>
> If you fix the issue, kindly add following tag as appropriate
> Reported-by: kernel test robot <lkp(a)intel.com>
>
>
> "sparse warnings: (new ones prefixed by >>)"
> arch/x86/hyperv/hv_init.c:90:30: sparse: sparse: incorrect type in initializer
(different address spaces) @@ expected void const [noderef] __percpu *__vpp_verify @@
got void [noderef] __percpu ** @@
> arch/x86/hyperv/hv_init.c:90:30: sparse: expected void const [noderef]
__percpu *__vpp_verify
> arch/x86/hyperv/hv_init.c:90:30: sparse: got void [noderef] __percpu **
> arch/x86/hyperv/hv_init.c:95:39: sparse: sparse: incorrect type in initializer
(different address spaces) @@ expected void const [noderef] __percpu *__vpp_verify @@
got void [noderef] __percpu ** @@
> arch/x86/hyperv/hv_init.c:95:39: sparse: expected void const [noderef]
__percpu *__vpp_verify
> arch/x86/hyperv/hv_init.c:95:39: sparse: got void [noderef] __percpu **
I don't think this class of issue is newly introduced specifically by
the Linux root partition changes.
Sparse is complaining the pointer types don't match. GCC doesn't
actually care.
Off the top of my head, this should be fixable by using the __force
annotation. But that means littering that everywhere. That does not look
nice.
Thoughts?
One way of doing it would be to provide helpers like
hv_get_hypercall_input_arg and hv_get_hypercall_output_arg. The __force
annotation is going to be enclosed with these two functions. We still
need to replace all the this_cpu_ptr(XXX) with the helpers, so code
churn is inevitable.
If people deem these issues important enough to fix and we agree on an
approach I don't mind writing a patch myself.
Wei.
>
> Wei.