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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAADnVQLpFZsRbMndY6nHqSWiAh3SfmN8S6KbJ9p9T_WC3x0i_g@mail.gmail.com>
Date: Wed, 16 Oct 2024 12:32:18 -0700
From: Alexei Starovoitov <alexei.starovoitov@...il.com>
To: Namhyung Kim <namhyung@...nel.org>
Cc: Stephen Rothwell <sfr@...b.auug.org.au>, Daniel Borkmann <daniel@...earbox.net>, 
	Alexei Starovoitov <ast@...nel.org>, Andrii Nakryiko <andrii@...nel.org>, bpf <bpf@...r.kernel.org>, 
	Networking <netdev@...r.kernel.org>, 
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>, 
	Linux Next Mailing List <linux-next@...r.kernel.org>
Subject: Re: linux-next: build failure after merge of the bpf-next tree

On Wed, Oct 16, 2024 at 11:35 AM Namhyung Kim <namhyung@...nel.org> wrote:
>
> On Wed, Oct 16, 2024 at 09:25:41AM -0700, Alexei Starovoitov wrote:
> > On Tue, Oct 15, 2024 at 11:05 PM Stephen Rothwell <sfr@...b.auug.org.au> wrote:
> > >
> > > Hi all,
> > >
> > > After merging the bpf-next tree, today's linux-next build (arm64
> > > defconfig) failed like this:
> > >
> > > Building: arm64 defconfig
> > > In file included from arch/arm64/include/asm/thread_info.h:17,
> > >                  from include/linux/thread_info.h:60,
> > >                  from arch/arm64/include/asm/preempt.h:6,
> > >                  from include/linux/preempt.h:79,
> > >                  from include/linux/spinlock.h:56,
> > >                  from include/linux/mmzone.h:8,
> > >                  from include/linux/gfp.h:7,
> > >                  from include/linux/slab.h:16,
> > >                  from mm/slab_common.c:7:
> > > mm/slab_common.c: In function 'bpf_get_kmem_cache':
> > > arch/arm64/include/asm/memory.h:427:66: error: passing argument 1 of 'virt_to_pfn' makes pointer from integer without a cast [-Wint-conversion]
> > >   427 |         __is_lm_address(__addr) && pfn_is_map_memory(virt_to_pfn(__addr));      \
> > >       |                                                                  ^~~~~~
> > >       |                                                                  |
> > >       |                                                                  u64 {aka long long unsigned int}
> > > mm/slab_common.c:1260:14: note: in expansion of macro 'virt_addr_valid'
> > >  1260 |         if (!virt_addr_valid(addr))
> > >       |              ^~~~~~~~~~~~~~~
> > > arch/arm64/include/asm/memory.h:382:53: note: expected 'const void *' but argument is of type 'u64' {aka 'long long unsigned int'}
> > >   382 | static inline unsigned long virt_to_pfn(const void *kaddr)
> > >       |                                         ~~~~~~~~~~~~^~~~~
> > >
> > > Caused by commit
> > >
> > >   04b069ff0181 ("mm/bpf: Add bpf_get_kmem_cache() kfunc")
> > >
> > > I have reverted commit
> > >
> > >   08c837461891 ("Merge branch 'bpf-add-kmem_cache-iterator-and-kfunc'")
> > >
> > > for today.
> >
> > Thanks for flagging.
> > Fixed and force pushed.
>
> Oops, thanks for fixing this.  The virt_addr_valid() was confusing
> whether it takes unsigned long or a pointer.  It seems each arch has
> different expectation.

        if (!virt_addr_valid((void *)(long)addr))

did the trick for me and that's what I pushed.
Odd that our bpf CI on arm64 didn't catch it.