Received-SPF: pass (google.com: domain of linux-kernel+bounces-89431-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) client-ip=2604:1380:40f1:3f00::1;
From: Thomas Gleixner <tglx@linutronix.de>
To: kernel test robot <lkp@intel.com>
Cc: oe-kbuild-all@lists.linux.dev, linux-kernel@vger.kernel.org, Arjan van
 de Ven <arjan@linux.intel.com>, x86@kernel.org
Subject: Re: arch/x86/include/asm/processor.h:698:16: sparse: sparse:
 incorrect type in initializer (different address spaces)
In-Reply-To: <87a5nhwpus.ffs@tglx>
References: <202403020457.RCJoQ3ts-lkp@intel.com> <87edctwr6y.ffs@tglx>
 <87a5nhwpus.ffs@tglx>
Date: Sat, 02 Mar 2024 12:37:29 +0100
Message-ID: <87y1b0vp8m.ffs@tglx>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain

On Fri, Mar 01 2024 at 23:26, Thomas Gleixner wrote:
> Sorry, my fault. I can reproduce now but it still does not make any
> sense. The code is correct...
>
> Let me put something together which the sparse folks can digest.

Bah. sparse is actually right. I completely missed the fact that this is
an UP build which has:

extern struct cpuinfo_x86	boot_cpu_data;

#define cpu_info		boot_cpu_data

So any access with this_cpu*(), per_cpu*() etc. is actually incorrect from
sparse's point of view.

From a compiler point of view it just works because __percpu dissolves
and the whole thing produces correct code magically.

Most places in x86 use cpu_data(cpu) to access per cpu data which is
defined as per_cpu(cpu_info, cpu) for SMP and boot_cpu_info for UP.

That's fine, but there are places like the MCE code which really needs
raw_cpu_ptr(). Sure we can write ugly wrappers for that and for some
other accessors. But that's all just wrong and ugly.

The proper solution would be to force SMP for x86, but Linus shot it
down when I wanted to do that last time.

Let me think about it.

Thanks,

        tglx