public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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

  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