Re: linux-next: build failure after merge of the tip tree

Jiri Slaby
2025-03-17T08:55:02Z

On 17. 03. 25, 6:05, Stephen Rothwell wrote:
> Hi all,
>
> On Tue, 11 Mar 2025 15:24:29 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>>
>> On Thu, 6 Mar 2025 15:25:16 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>>>
>>> On Tue, 4 Mar 2025 16:25:31 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>>>>
>>>> After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
>>>> failed like this:
>>>>
>>>> In file included from include/asm-generic/percpu.h:7,
>>>> from arch/x86/include/asm/percpu.h:597,
>>>> from arch/x86/include/asm/preempt.h:6,
>>>> from include/linux/preempt.h:79,
>>>> from include/linux/spinlock.h:56,
>>>> from include/linux/wait.h:9,
>>>> from include/linux/wait_bit.h:8,
>>>> from include/linux/fs.h:7,
>>>> from kernel/events/core.c:11:
>>>> kernel/events/core.c: In function 'this_cpc':
>>>> include/linux/percpu-defs.h:220:45: error: initialization from pointer to non-enclosed address space
>>>> 220 | const void __percpu *__vpp_verify = (typeof((ptr) + 0))NULL; \
>>>> | ^
>>>> include/linux/percpu-defs.h:251:9: note: in expansion of macro '__verify_pcpu_ptr'
>>>> 251 | __verify_pcpu_ptr(ptr); \
>>>> | ^~~~~~~~~~~~~~~~~
>>>> kernel/events/core.c:1222:17: note: in expansion of macro 'this_cpu_ptr'
>>>> 1222 | return *this_cpu_ptr(pmu->cpu_pmu_context);
>>>> | ^~~~~~~~~~~~
>>>>
>>>> (and many more similar)
>>>>
>>>> Presumably caused by commit
>>>>
>>>> f67d1ffd841f ("perf/core: Detach 'struct perf_cpu_pmu_context' and 'struct pmu' lifetimes")
>>>>
>>>> I have used the tip tree from next-20250303 for today.
>>>
>>> I am still seeing this build failure.
>>
>> Ditto. Anything happening with this?
>>
>> I am still using the tip tree from next-20250303.
>
> So am I missing something here? I am still seeing this build failure.
>
> That commit is now
>
> 4eabf533fb18 ("perf/core: Detach 'struct perf_cpu_pmu_context' and 'struct pmu' lifetimes")
>
> Is there something in my toolchain? Or some other difference in our
> build environments?

FWIW I cannot reproduce with gcc 14 or 9. tip/master builds that file
fine for me. Perhaps a merge with some other tree introduces this?

thanks,
--
js
suse labs