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)
Date: Sat, 02 Mar 2024 12:37:29 +0100 [thread overview]
Message-ID: <87y1b0vp8m.ffs@tglx> (raw)
In-Reply-To: <87a5nhwpus.ffs@tglx>
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
next prev parent reply other threads:[~2024-03-02 11:37 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-01 20:12 arch/x86/include/asm/processor.h:698:16: sparse: sparse: incorrect type in initializer (different address spaces) kernel test robot
2024-03-01 21:57 ` Thomas Gleixner
2024-03-01 22:26 ` Thomas Gleixner
2024-03-02 9:43 ` Philip Li
2024-03-02 11:37 ` Thomas Gleixner [this message]
2024-03-02 15:44 ` Thomas Gleixner
2024-03-02 22:00 ` Thomas Gleixner
2024-03-02 22:49 ` Linus Torvalds
2024-03-03 16:31 ` Thomas Gleixner
2024-03-03 19:03 ` Uros Bizjak
2024-03-03 20:10 ` Thomas Gleixner
2024-03-03 20:21 ` Uros Bizjak
2024-03-03 20:24 ` Uros Bizjak
2024-03-03 21:19 ` Uros Bizjak
2024-03-03 23:49 ` Thomas Gleixner
2024-03-04 5:42 ` Uros Bizjak
2024-03-04 7:07 ` Thomas Gleixner
2024-04-02 11:43 ` Uros Bizjak
2024-04-03 17:57 ` Nathan Chancellor
2024-04-04 6:56 ` Uros Bizjak
2024-04-29 21:30 ` [RFC PATCH] Use x86 named address spaces to catch "sparse: incorrect type in initializer (different address spaces)" __percpu errors Uros Bizjak
2024-03-02 12:53 ` arch/x86/include/asm/processor.h:698:16: sparse: sparse: incorrect type in initializer (different address spaces) Yujie Liu
-- strict thread matches above, loose matches on Subject: below --
2024-01-09 20:00 kernel test robot
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87y1b0vp8m.ffs@tglx \
--to=tglx@linutronix.de \
--cc=arjan@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lkp@intel.com \
--cc=oe-kbuild-all@lists.linux.dev \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox