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

[Kumar Kartikeya Dwivedi]

On Wed, 19 Mar 2025 at 14:37, Kumar Kartikeya Dwivedi <memxor@xxxxxxxxx> wrote:
>
> On Wed, 19 Mar 2025 at 03:47, Alexei Starovoitov
> <alexei.starovoitov@xxxxxxxxx> wrote:
> >
> > On Tue, Mar 18, 2025 at 7:33 PM Stephen Rothwell <sfr@xxxxxxxxxxxxxxxx> wrote:
> > >
> > > Hi all,
> > >
> > > After merging the bpf-next 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:630,
> > >                  from arch/x86/include/asm/preempt.h:6,
> > >                  from include/linux/preempt.h:79,
> > >                  from include/linux/smp.h:116,
> > >                  from kernel/locking/qspinlock.c:16:
> > > kernel/locking/qspinlock.h: In function 'decode_tail':
> > > include/linux/percpu-defs.h:219:45: error: initialization from pointer to non-enclosed address space
> > >   219 |         const void __percpu *__vpp_verify = (typeof((ptr) + 0))NULL;    \
> > >       |                                             ^
> > > include/linux/percpu-defs.h:237:9: note: in expansion of macro '__verify_pcpu_ptr'
> > >   237 |         __verify_pcpu_ptr(ptr);                                         \
> > >       |         ^~~~~~~~~~~~~~~~~
> > > kernel/locking/qspinlock.h:67:16: note: in expansion of macro 'per_cpu_ptr'
> > >    67 |         return per_cpu_ptr(&qnodes[idx].mcs, cpu);
> > >       |                ^~~~~~~~~~~
> > > include/linux/percpu-defs.h:219:45: note: expected 'const __seg_gs void *' but pointer is of type 'struct mcs_spinlock *'
> > >   219 |         const void __percpu *__vpp_verify = (typeof((ptr) + 0))NULL;    \
> > >       |                                             ^
> > > include/linux/percpu-defs.h:237:9: note: in expansion of macro '__verify_pcpu_ptr'
> > >   237 |         __verify_pcpu_ptr(ptr);                                         \
> > >       |         ^~~~~~~~~~~~~~~~~
> > > kernel/locking/qspinlock.h:67:16: note: in expansion of macro 'per_cpu_ptr'
> > >    67 |         return per_cpu_ptr(&qnodes[idx].mcs, cpu);
> > >       |                ^~~~~~~~~~~
> > > kernel/locking/qspinlock.c: In function 'native_queued_spin_lock_slowpath':
> > > kernel/locking/qspinlock.c:285:41: error: passing argument 2 of 'decode_tail' from pointer to non-enclosed address space
> > >   285 |                 prev = decode_tail(old, qnodes);
> > >       |                                         ^~~~~~
> > > In file included from kernel/locking/qspinlock.c:30:
> > > kernel/locking/qspinlock.h:62:79: note: expected 'struct qnode *' but argument is of type '__seg_gs struct qnode *'
> > >    62 | static inline __pure struct mcs_spinlock *decode_tail(u32 tail, struct qnode *qnodes)
> > >       |                                                                 ~~~~~~~~~~~~~~^~~~~~
> > > In file included from kernel/locking/qspinlock.c:401:
> > > kernel/locking/qspinlock.c: In function '__pv_queued_spin_lock_slowpath':
> > > kernel/locking/qspinlock.c:285:41: error: passing argument 2 of 'decode_tail' from pointer to non-enclosed address space
> > >   285 |                 prev = decode_tail(old, qnodes);
> > >       |                                         ^~~~~~
> > > kernel/locking/qspinlock.h:62:79: note: expected 'struct qnode *' but argument is of type '__seg_gs struct qnode *'
> > >    62 | static inline __pure struct mcs_spinlock *decode_tail(u32 tail, struct qnode *qnodes)
> > >       |                                                                 ~~~~~~~~~~~~~~^~~~~~
> > >
> > > Caused by the resilient-queued-spin-lock branch of the bpf-next tree
> > > interacting with the "Enable strict percpu address space checks" series
> > > form the mm-stable tree.
> >
> > Do you mean this set:
> > https://lore.kernel.org/all/20250127160709.80604-1-ubizjak@xxxxxxxxx/
> >
> > >
> > > I don't know why this happens, but reverting that branch inf the bpf-next
> > > tree makes the failure go away, so I have done that for today.
> >
> > Kumar,
> >
> > pls take a look.
>
> I've sent a fix [0], but unfortunately I was unable to reproduce the
> problem with an LLVM >= 19 build, idk why. I will try with GCC >= 14
> as the patches require to confirm, but based on the error I am 99%
> sure it will fix the problem.

Probably because __seg_gs has CC_HAS_NAMED_AS depends on CC_IS_GCC.
Let me give it a go with GCC.

>
> [0] https://lore.kernel.org/bpf/20250319133523.641009-1-memxor@xxxxxxxxx
>
> Feel free to cherry-pick or squash into the fixed commit, whatever is best.