* Thomas Gleixner <tglx@xxxxxxxxxxxxx> 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
