From: Ingo Molnar <mingo@kernel.org>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: LKML <linux-kernel@vger.kernel.org>,
x86@kernel.org, Linus Torvalds <torvalds@linuxfoundation.org>,
Uros Bizjak <ubizjak@gmail.com>,
linux-sparse@vger.kernel.org, lkp@intel.com,
oe-kbuild-all@lists.linux.dev
Subject: Re: [patch 0/9] x86: Cure tons of sparse warnings (mostly __percpu)
Date: Mon, 4 Mar 2024 12:08:24 +0100 [thread overview]
Message-ID: <ZeWrqNcbSFJrQddR@gmail.com> (raw)
In-Reply-To: <20240303235029.555787150@linutronix.de>
* Thomas Gleixner <tglx@linutronix.de> wrote:
> A recent 0-day report about new __percpu related sparse warnings made me
> look deeper into it after I dismissed the report as bogus initially.
>
> It turned out that sparse is actually right and all of these warnings (not
> only the most recent ones) are valid and got ignored. Some of them for many
> years.
>
> The worst offender is an UP build because that maps the per CPU cpu_info to
> boot_cpu_data, which is regular data.
>
> As a consequence all per CPU accessors which look like legit code and are
> legit code in the SMP build are causing sparse to emit warnings.
>
> This series addresses this by:
>
> - Adding the missing __percpu annotations all over the place
>
> - Curing the UP madness by exposing a proper per CPU cpu_info for the
> price of wasting 320 byte of memory.
>
> Even if the size police will hate me for that, this cures most of
> the madness in one go and avoids to add more hideous macro mess
> similar to the completely bogus cpu_data() one which should have
> never been there in the first place.
The market of UP-only systems running an upstream Linux kernel is shrinking
fast, so I doubt this is a real concern.
> I know that there are people who think that size matters, but the
> only things which really matter in software are correctness and
> maintainability. The latter simply forbids to add more hideous macro
> mess just to avoid wasting 320 bytes of memory for something which
> is mostly a reminiscence of the good old days...
>
> - Fixing a few obvious non __percpu related warnings which stood out
> prominently.
>
> That reduces the sparse warnings in arch/x86 significantly.
Great - there's also the side benefit of reduction in <asm/processor.h>
complexity via patch #2, which is great for ongoing work to reduce header
depdency hell ...
I've applied your Sparse fixes to tip:x86/cleanups straight away, so they
have a chance to make it into v6.9.
Thanks,
Ingo
prev parent reply other threads:[~2024-03-04 11:08 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-04 10:12 [patch 0/9] x86: Cure tons of sparse warnings (mostly __percpu) Thomas Gleixner
2024-03-04 10:12 ` [patch 1/9] perf/x86/amd/uncore: Fix __percpu annotation Thomas Gleixner
2024-03-04 12:15 ` [tip: x86/cleanups] " tip-bot2 for Thomas Gleixner
2024-03-04 10:12 ` [patch 2/9] x86/msr: Prepare for including percpu.h Thomas Gleixner
2024-03-04 12:15 ` [tip: x86/cleanups] x86/msr: Prepare for including <linux/percpu.h> into <asm/msr.h> tip-bot2 for Thomas Gleixner
2024-03-04 10:12 ` [patch 3/9] x86/msr: Add missing __percpu annotations Thomas Gleixner
2024-03-04 12:15 ` [tip: x86/cleanups] " tip-bot2 for Thomas Gleixner
2024-03-04 10:12 ` [patch 4/9] smp: Consolidate smp_prepare_boot_cpu() Thomas Gleixner
2024-03-04 12:15 ` [tip: x86/cleanups] " tip-bot2 for Thomas Gleixner
2024-03-04 10:12 ` [patch 5/9] x86: Cure per CPU madness on UP Thomas Gleixner
2024-03-04 12:15 ` [tip: x86/cleanups] x86/percpu: " tip-bot2 for Thomas Gleixner
2024-03-15 16:17 ` [patch 5/9] x86: " Guenter Roeck
2024-03-15 16:42 ` Linus Torvalds
2024-03-15 17:02 ` Guenter Roeck
2024-03-15 17:40 ` Thomas Gleixner
2024-03-15 22:55 ` Thomas Gleixner
2024-03-15 23:23 ` Linus Torvalds
2024-03-16 1:11 ` Thomas Gleixner
2024-03-16 1:23 ` Linus Torvalds
2024-03-16 21:34 ` Arnd Bergmann
2024-03-17 21:03 ` David Laight
2024-03-18 11:11 ` Thomas Gleixner
2024-03-18 17:27 ` Thomas Gleixner
2024-03-18 19:13 ` Arnd Bergmann
2024-03-19 16:21 ` Thomas Gleixner
2024-03-19 18:26 ` Guenter Roeck
2024-03-16 0:56 ` Guenter Roeck
2024-03-20 8:58 ` Thomas Gleixner
2024-03-20 15:46 ` Guenter Roeck
2024-03-21 11:14 ` Thomas Gleixner
2024-03-21 14:06 ` Guenter Roeck
2024-03-21 16:49 ` Thomas Gleixner
2024-03-04 10:12 ` [patch 6/9] x86/uaccess: Add missing __force to casts in __access_ok() and valid_user_address() Thomas Gleixner
2024-03-04 12:15 ` [tip: x86/cleanups] " tip-bot2 for Thomas Gleixner
2024-03-04 10:12 ` [patch 7/9] x86/cpu: Use EXPORT_PER_CPU_SYMBOL_GPL() for x86_spec_ctrl_current Thomas Gleixner
2024-03-04 12:15 ` [tip: x86/cleanups] " tip-bot2 for Thomas Gleixner
2024-03-04 10:12 ` [patch 8/9] x86/cpu: Provide a declaration for itlb_multihit_kvm_mitigation Thomas Gleixner
2024-03-04 12:15 ` [tip: x86/cleanups] " tip-bot2 for Thomas Gleixner
2024-03-04 10:12 ` [patch 9/9] x86/callthunks: Use EXPORT_PER_CPU_SYMBOL_GPL() for per CPU variables Thomas Gleixner
2024-03-04 12:15 ` [tip: x86/cleanups] " tip-bot2 for Thomas Gleixner
2024-03-04 11:08 ` Ingo Molnar [this message]
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=ZeWrqNcbSFJrQddR@gmail.com \
--to=mingo@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-sparse@vger.kernel.org \
--cc=lkp@intel.com \
--cc=oe-kbuild-all@lists.linux.dev \
--cc=tglx@linutronix.de \
--cc=torvalds@linuxfoundation.org \
--cc=ubizjak@gmail.com \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.