Re: linux-next: build failure after merge of the bpf-next tree
Hi all,
On Fri, 12 Mar 2021 12:00:14 +1100 Stephen Rothwell
wrote:
>
> [Cc'ing a few (maybe) interested parties]
>
> On Thu, 11 Mar 2021 07:47:03 +0100 Björn Töpel wrote:
> >
> > On 2021-03-11 01:47, Stephen Rothwell wrote:
> > >
> > > After merging the bpf-next tree, today's linux-next build (perf) failed
> > > like this:
> > >
> > > make[3]: *** No rule to make target 'libbpf_util.h', needed by
> > > '/home/sfr/next/perf/staticobjs/xsk.o'. Stop.
> >
> > It's an incremental build issue, as pointed out here [1], that is
> > resolved by cleaning the build.
>
> Does this mean there is a deficiency in the dependencies in our build system?
>
> > [1]
> > https://lore.kernel.org/bpf/CAEf4BzYPDF87At4=_gsndxof84oiqyjxgahl7_jvpuntovu...@mail.gmail.com/
> >
> > > Caused by commit
> > >
> > >7e8bbe24cb8b ("libbpf: xsk: Move barriers from libbpf_util.h to xsk.h")
> > >
> > > I have used the bpf tree from next-20210310 for today.
>
> I have set my system to remove the object directory before building
> after merging the bpf-next tree for now.
I now get this build failure after I merge the net-next tree :-(
--
Cheers,
Stephen Rothwell
pgpsF3Rzr8LNE.pgp
Description: OpenPGP digital signature
Re: linux-next: build failure after merge of the bpf-next tree
Hi Björn,
[Cc'ing a few (maybe) interested parties]
On Thu, 11 Mar 2021 07:47:03 +0100 Björn Töpel wrote:
>
> On 2021-03-11 01:47, Stephen Rothwell wrote:
> >
> > After merging the bpf-next tree, today's linux-next build (perf) failed
> > like this:
> >
> > make[3]: *** No rule to make target 'libbpf_util.h', needed by
> > '/home/sfr/next/perf/staticobjs/xsk.o'. Stop.
>
> It's an incremental build issue, as pointed out here [1], that is
> resolved by cleaning the build.
Does this mean there is a deficiency in the dependencies in our build system?
> [1]
> https://lore.kernel.org/bpf/CAEf4BzYPDF87At4=_gsndxof84oiqyjxgahl7_jvpuntovu...@mail.gmail.com/
>
> > Caused by commit
> >
> >7e8bbe24cb8b ("libbpf: xsk: Move barriers from libbpf_util.h to xsk.h")
> >
> > I have used the bpf tree from next-20210310 for today.
I have set my system to remove the object directory before building
after merging the bpf-next tree for now.
--
Cheers,
Stephen Rothwell
pgpmytPelLBlo.pgp
Description: OpenPGP digital signature
Re: linux-next: build failure after merge of the bpf-next tree
On 2021-03-11 01:47, Stephen Rothwell wrote:
Hi all,
After merging the bpf-next tree, today's linux-next build (perf) failed
like this:
make[3]: *** No rule to make target 'libbpf_util.h', needed by
'/home/sfr/next/perf/staticobjs/xsk.o'. Stop.
Hi Stephen,
It's an incremental build issue, as pointed out here [1], that is
resolved by cleaning the build.
Cheers,
Björn
[1]
https://lore.kernel.org/bpf/CAEf4BzYPDF87At4=_gsndxof84oiqyjxgahl7_jvpuntovu...@mail.gmail.com/
Caused by commit
7e8bbe24cb8b ("libbpf: xsk: Move barriers from libbpf_util.h to xsk.h")
I have used the bpf tree from next-20210310 for today.
Re: linux-next: build failure after merge of the bpf-next tree
On 12/1/20 9:07 AM, Stephen Rothwell wrote:
Hi all,
After merging the bpf-next tree, today's linux-next build (x86_64
allnoconfig) failed like this:
In file included from fs/select.c:32:
include/net/busy_poll.h: In function 'sk_mark_napi_id_once':
include/net/busy_poll.h:150:36: error: 'const struct sk_buff' has no member
named 'napi_id'
150 | __sk_mark_napi_id_once_xdp(sk, skb->napi_id);
|^~
Caused by commit
b02e5a0ebb17 ("xsk: Propagate napi_id to XDP socket Rx path")
Fixed it up in bpf-next, thanks for reporting!
Re: linux-next: build failure after merge of the bpf-next tree
On 9/7/20 8:08 PM, Stephen Rothwell wrote:
Hi all,
After merging the bpf-next tree, today's linux-next build (powerpcle perf)
failed like this:
util/bpf-loader.c: In function 'config_bpf_program':
util/bpf-loader.c:331:2: error: 'bpf_program__title' is deprecated: BPF program
title is confusing term; please use bpf_program__section_name() instead
[-Werror=deprecated-declarations]
331 | config_str = bpf_program__title(prog, false);
| ^~
In file included from util/bpf-loader.c:10:
tools/lib/bpf/libbpf.h:203:13: note: declared here
203 | const char *bpf_program__title(const struct bpf_program *prog, bool
needs_copy);
| ^~
util/bpf-loader.c: In function 'preproc_gen_prologue':
util/bpf-loader.c:457:3: error: 'bpf_program__title' is deprecated: BPF program
title is confusing term; please use bpf_program__section_name() instead
[-Werror=deprecated-declarations]
457 | title = bpf_program__title(prog, false);
| ^
In file included from util/bpf-loader.c:10:
tools/lib/bpf/libbpf.h:203:13: note: declared here
203 | const char *bpf_program__title(const struct bpf_program *prog, bool
needs_copy);
| ^~
cc1: all warnings being treated as errors
Caused or exposed by commit
521095842027 ("libbpf: Deprecate notion of BPF program "title" in favor of "section
name"")
I have used the bpf-next tree from next-20200903 for today.
perf code is using deprecated bpf_program__title() API. I'll send a
patch for bpf-next to replace it with bpf_program__section_name().
Thanks for letting me know about build warning!
Re: linux-next: build failure after merge of the bpf-next tree
Hi Alexei, On Tue, 25 Aug 2020 15:34:52 -0700 Alexei Starovoitov wrote: > > On Tue, Aug 25, 2020 at 2:10 PM Stephen Rothwell > wrote: > > > > Hi Alexei, > > > > On Tue, 25 Aug 2020 07:33:51 -0700 Alexei Starovoitov > > wrote: > > > > > > what do you suggest to use to make it 'manually enabled' ? > > > All I could think of is to add: > > > depends on !COMPILE_TEST > > > so that allmodconfig doesn't pick it up. > > > > That is probably sufficient. Some gcc plugins and kasan bits, etc use > > just that. > > Ok. Pushed the silencing 'fix': > https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git/commit/?id=2532f849b5134c4c62a20e5aaca33d9fb08af528 Thanks for that. -- Cheers, Stephen Rothwell pgpGQaL_wFq81.pgp Description: OpenPGP digital signature
Re: linux-next: build failure after merge of the bpf-next tree
On Tue, Aug 25, 2020 at 2:10 PM Stephen Rothwell wrote: > > Hi Alexei, > > On Tue, 25 Aug 2020 07:33:51 -0700 Alexei Starovoitov > wrote: > > > > what do you suggest to use to make it 'manually enabled' ? > > All I could think of is to add: > > depends on !COMPILE_TEST > > so that allmodconfig doesn't pick it up. > > That is probably sufficient. Some gcc plugins and kasan bits, etc use > just that. Ok. Pushed the silencing 'fix': https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git/commit/?id=2532f849b5134c4c62a20e5aaca33d9fb08af528
Re: linux-next: build failure after merge of the bpf-next tree
Hi Alexei, On Tue, 25 Aug 2020 07:33:51 -0700 Alexei Starovoitov wrote: > > what do you suggest to use to make it 'manually enabled' ? > All I could think of is to add: > depends on !COMPILE_TEST > so that allmodconfig doesn't pick it up. That is probably sufficient. Some gcc plugins and kasan bits, etc use just that. -- Cheers, Stephen Rothwell pgpaNg3QL2Zbk.pgp Description: OpenPGP digital signature
Re: linux-next: build failure after merge of the bpf-next tree
On Mon, Aug 24, 2020 at 11:50 PM Stephen Rothwell wrote: > > Hi Alexei, > > On Mon, 24 Aug 2020 20:27:28 -0700 Alexei Starovoitov > wrote: > > > > I didn't receive the first email you've replied to. > > The build error is: > > " > > No libelf found > > make[5]: *** [Makefile:284: elfdep] Error 1 > > " > > and build process stops because libelf is not found, right? > > That is expected and necessary. > > bpf_preload needs libbpf that depends on libelf. > > The only 'fix' is to turn off bpf_preload. > > It's off by default. > > allmodconfig cannot build bpf_preload umd if there is no libelf. > > There is CC_CAN_LINK that does feature detection. > > We can extend scripts/cc-can-link.sh or add another script that > > will do CC_CAN_LINK_LIBELF, but such approach doesn't scale. > > imo it's cleaner to rely on feature detection by libbpf Makefile with > > an error above instead of adding such knobs to top Kconfig. > > Does it make sense? > > Sorry, but if this is not necessary to build the kernel, then an > allmodconfig build needs to succeed so you need to do the detection and > turn it off automatically. Or you could make it so that it has to be > manually enabled in all circumstances. what do you suggest to use to make it 'manually enabled' ? All I could think of is to add: depends on !COMPILE_TEST so that allmodconfig doesn't pick it up.
Re: linux-next: build failure after merge of the bpf-next tree
Hi Alexei, On Mon, 24 Aug 2020 20:27:28 -0700 Alexei Starovoitov wrote: > > I didn't receive the first email you've replied to. > The build error is: > " > No libelf found > make[5]: *** [Makefile:284: elfdep] Error 1 > " > and build process stops because libelf is not found, right? > That is expected and necessary. > bpf_preload needs libbpf that depends on libelf. > The only 'fix' is to turn off bpf_preload. > It's off by default. > allmodconfig cannot build bpf_preload umd if there is no libelf. > There is CC_CAN_LINK that does feature detection. > We can extend scripts/cc-can-link.sh or add another script that > will do CC_CAN_LINK_LIBELF, but such approach doesn't scale. > imo it's cleaner to rely on feature detection by libbpf Makefile with > an error above instead of adding such knobs to top Kconfig. > Does it make sense? Sorry, but if this is not necessary to build the kernel, then an allmodconfig build needs to succeed so you need to do the detection and turn it off automatically. Or you could make it so that it has to be manually enabled in all circumstances. -- Cheers, Stephen Rothwell pgpwUS71MlNgk.pgp Description: OpenPGP digital signature
Re: linux-next: build failure after merge of the bpf-next tree
On Mon, Aug 24, 2020 at 8:04 PM Stephen Rothwell wrote:
>
> Hi Alexei,
>
> On Mon, 24 Aug 2020 18:25:44 -0700 Alexei Starovoitov
> wrote:
> >
> > On Mon, Aug 24, 2020 at 6:20 PM Stephen Rothwell
> > wrote:
> > >
> > > On Fri, 21 Aug 2020 11:11:11 +1000 Stephen Rothwell
> > > wrote:
> > > >
> > > > After merging the bpf-next tree, today's linux-next build (x86_64
> > > > allmodconfig) failed like this:
> > > >
> > > > Auto-detecting system features:
> > > > ...libelf: [ [31mOFF [m ]
> > > > ... zlib: [ [31mOFF [m ]
> > > > ... bpf: [ [32mon [m ]
> > > >
> > > > No libelf found
> > > > make[5]: *** [Makefile:284: elfdep] Error 1
> > > >
> > > > Caused by commit
> > > >
> > > > d71fa5c9763c ("bpf: Add kernel module with user mode driver that
> > > > populates bpffs.")
> > > >
> > > > [For a start, can we please *not* add this verbose feature detection
> > > > output to the nrormal build?]
> > > >
> > > > This is a PowerPC hosted cross build.
> > > >
> > > > I have marked BPF_PRELOAD as BROKEN for now.
> > >
> > > Still getting this failure ...
> >
> > I don't have powerpc with crosscompiler to x86 to reproduce.
> > What exactly the error?
>
> Just as above.
I didn't receive the first email you've replied to.
The build error is:
"
No libelf found
make[5]: *** [Makefile:284: elfdep] Error 1
"
and build process stops because libelf is not found, right?
That is expected and necessary.
bpf_preload needs libbpf that depends on libelf.
The only 'fix' is to turn off bpf_preload.
It's off by default.
allmodconfig cannot build bpf_preload umd if there is no libelf.
There is CC_CAN_LINK that does feature detection.
We can extend scripts/cc-can-link.sh or add another script that
will do CC_CAN_LINK_LIBELF, but such approach doesn't scale.
imo it's cleaner to rely on feature detection by libbpf Makefile with
an error above instead of adding such knobs to top Kconfig.
Does it make sense?
Re: linux-next: build failure after merge of the bpf-next tree
Hi Alexei,
On Mon, 24 Aug 2020 18:25:44 -0700 Alexei Starovoitov
wrote:
>
> On Mon, Aug 24, 2020 at 6:20 PM Stephen Rothwell
> wrote:
> >
> > On Fri, 21 Aug 2020 11:11:11 +1000 Stephen Rothwell
> > wrote:
> > >
> > > After merging the bpf-next tree, today's linux-next build (x86_64
> > > allmodconfig) failed like this:
> > >
> > > Auto-detecting system features:
> > > ...libelf: [ [31mOFF [m ]
> > > ... zlib: [ [31mOFF [m ]
> > > ... bpf: [ [32mon [m ]
> > >
> > > No libelf found
> > > make[5]: *** [Makefile:284: elfdep] Error 1
> > >
> > > Caused by commit
> > >
> > > d71fa5c9763c ("bpf: Add kernel module with user mode driver that
> > > populates bpffs.")
> > >
> > > [For a start, can we please *not* add this verbose feature detection
> > > output to the nrormal build?]
> > >
> > > This is a PowerPC hosted cross build.
> > >
> > > I have marked BPF_PRELOAD as BROKEN for now.
> >
> > Still getting this failure ...
>
> I don't have powerpc with crosscompiler to x86 to reproduce.
> What exactly the error?
Just as above.
> bpf_preload has:
> "depends on CC_CAN_LINK"
> which is exactly the same as bpfilter.
> You should have seen this issue with bpfilter for years now.
Well, I haven't :-) It just started the other day when that commit
appeared.
--
Cheers,
Stephen Rothwell
pgpoJy5Mw2XeS.pgp
Description: OpenPGP digital signature
Re: linux-next: build failure after merge of the bpf-next tree
On Mon, Aug 24, 2020 at 6:20 PM Stephen Rothwell wrote:
>
> Hi all,
>
> On Fri, 21 Aug 2020 11:11:11 +1000 Stephen Rothwell
> wrote:
> >
> > Hi all,
> >
> > After merging the bpf-next tree, today's linux-next build (x86_64
> > allmodconfig) failed like this:
> >
> > Auto-detecting system features:
> > ...libelf: [ [31mOFF [m ]
> > ... zlib: [ [31mOFF [m ]
> > ... bpf: [ [32mon [m ]
> >
> > No libelf found
> > make[5]: *** [Makefile:284: elfdep] Error 1
> >
> > Caused by commit
> >
> > d71fa5c9763c ("bpf: Add kernel module with user mode driver that
> > populates bpffs.")
> >
> > [For a start, can we please *not* add this verbose feature detection
> > output to the nrormal build?]
> >
> > This is a PowerPC hosted cross build.
> >
> > I have marked BPF_PRELOAD as BROKEN for now.
>
> Still getting this failure ...
I don't have powerpc with crosscompiler to x86 to reproduce.
What exactly the error?
bpf_preload has:
"depends on CC_CAN_LINK"
which is exactly the same as bpfilter.
You should have seen this issue with bpfilter for years now.
Re: linux-next: build failure after merge of the bpf-next tree
Hi all,
On Fri, 21 Aug 2020 11:11:11 +1000 Stephen Rothwell
wrote:
>
> Hi all,
>
> After merging the bpf-next tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> Auto-detecting system features:
> ...libelf: [ [31mOFF[m ]
> ... zlib: [ [31mOFF[m ]
> ... bpf: [ [32mon[m ]
>
> No libelf found
> make[5]: *** [Makefile:284: elfdep] Error 1
>
> Caused by commit
>
> d71fa5c9763c ("bpf: Add kernel module with user mode driver that populates
> bpffs.")
>
> [For a start, can we please *not* add this verbose feature detection
> output to the nrormal build?]
>
> This is a PowerPC hosted cross build.
>
> I have marked BPF_PRELOAD as BROKEN for now.
Still getting this failure ...
--
Cheers,
Stephen Rothwell
pgpqgf0XtMrhC.pgp
Description: OpenPGP digital signature
Re: linux-next: build failure after merge of the bpf-next tree
Hi Jiri,
On Tue, Jul 14, 2020 at 10:33 AM Jiri Olsa wrote:
> On Tue, Jul 14, 2020 at 08:16:54AM +0200, Jiri Olsa wrote:
> > On Tue, Jul 14, 2020 at 12:22:47PM +1000, Stephen Rothwell wrote:
> > > After merging the bpf-next tree, today's linux-next build (arm
> > > multi_v7_defconfig) failed like this:
> > >
> > > tmp/ccsqpVCY.s: Assembler messages:
> > > tmp/ccsqpVCY.s:78: Error: unrecognized symbol type ""
> > > tmp/ccsqpVCY.s:91: Error: unrecognized symbol type ""
> > >
> > > I don't know what has caused this (I guess maybe the resolve_btfids
> > > branch).
> > >
> > > I have used the bpf-next tree from next-20200713 for today.
Bummer, didn't find this report before I had bisected this to
c9a0f3b85e09dd16 ("bpf: Resolve BTF IDs in vmlinux image"), and
investigated the root cause (@object) myself, as the failing file path
(net/core/filter.o) was not mentioned...
> > ok, trying to reproduce
>
> damn crossbuilds.. change below fixes it for me,
> will do some more testing and post it today
Thanks, this fixes my (cross)arm32 build, and the (cross)arm64 build
keeps working, and everything boots, so
Tested-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: linux-next: build failure after merge of the bpf-next tree
On Tue, Jul 14, 2020 at 08:16:54AM +0200, Jiri Olsa wrote: > On Tue, Jul 14, 2020 at 12:22:47PM +1000, Stephen Rothwell wrote: > > Hi all, > > > > After merging the bpf-next tree, today's linux-next build (arm > > multi_v7_defconfig) failed like this: > > > > tmp/ccsqpVCY.s: Assembler messages: > > tmp/ccsqpVCY.s:78: Error: unrecognized symbol type "" > > tmp/ccsqpVCY.s:91: Error: unrecognized symbol type "" > > > > I don't know what has caused this (I guess maybe the resolve_btfids > > branch). > > > > I have used the bpf-next tree from next-20200713 for today. > > ok, trying to reproduce damn crossbuilds.. change below fixes it for me, will do some more testing and post it today jirka --- diff --git a/include/linux/btf_ids.h b/include/linux/btf_ids.h index fe019774f8a7..8b9194e22c7c 100644 --- a/include/linux/btf_ids.h +++ b/include/linux/btf_ids.h @@ -21,7 +21,7 @@ asm( \ ".pushsection " BTF_IDS_SECTION ",\"a\"; \n" \ ".local " #symbol " ; \n" \ -".type " #symbol ", @object; \n" \ +".type " #symbol ", STT_OBJECT; \n" \ ".size " #symbol ", 4;\n" \ #symbol ": \n" \ ".zero 4 \n" \ diff --git a/tools/bpf/resolve_btfids/Makefile b/tools/bpf/resolve_btfids/Makefile index 948378ca73d4..a88cd4426398 100644 --- a/tools/bpf/resolve_btfids/Makefile +++ b/tools/bpf/resolve_btfids/Makefile @@ -16,6 +16,20 @@ else MAKEFLAGS=--no-print-directory endif +# always use the host compiler +ifneq ($(LLVM),) +HOSTAR ?= llvm-ar +HOSTCC ?= clang +HOSTLD ?= ld.lld +else +HOSTAR ?= ar +HOSTCC ?= gcc +HOSTLD ?= ld +endif +AR = $(HOSTAR) +CC = $(HOSTCC) +LD = $(HOSTLD) + OUTPUT ?= $(srctree)/tools/bpf/resolve_btfids/ LIBBPF_SRC := $(srctree)/tools/lib/bpf/
Re: linux-next: build failure after merge of the bpf-next tree
On Tue, Jul 14, 2020 at 12:22:47PM +1000, Stephen Rothwell wrote: > Hi all, > > After merging the bpf-next tree, today's linux-next build (arm > multi_v7_defconfig) failed like this: > > tmp/ccsqpVCY.s: Assembler messages: > tmp/ccsqpVCY.s:78: Error: unrecognized symbol type "" > tmp/ccsqpVCY.s:91: Error: unrecognized symbol type "" > > I don't know what has caused this (I guess maybe the resolve_btfids > branch). > > I have used the bpf-next tree from next-20200713 for today. ok, trying to reproduce thanks, jirka
Re: linux-next: build failure after merge of the bpf-next tree
Hi all,
On Mon, 1 Jul 2019 14:57:22 +1000 Stephen Rothwell
wrote:
>
> After merging the bpf-next tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> drivers/net/ethernet/mellanox/mlx5/core/en_main.c:1605:5: error: conflicting
> types for 'mlx5e_open_cq'
> int mlx5e_open_cq(struct mlx5e_channel *c, struct dim_cq_moder moder,
> ^
> In file included from drivers/net/ethernet/mellanox/mlx5/core/en_main.c:43:
> drivers/net/ethernet/mellanox/mlx5/core/en.h:977:5: note: previous
> declaration of 'mlx5e_open_cq' was here
> int mlx5e_open_cq(struct mlx5e_channel *c, struct net_dim_cq_moder moder,
> ^
>
> Caused by commit
>
> 8960b38932be ("linux/dim: Rename externally used net_dim members")
>
> from the net-next tree interacting with commit
>
> db05815b36cb ("net/mlx5e: Add XSK zero-copy support")
>
> I have applied the following merge fix patch.
>
> From 8e92dbee0daa6bac412daebd08073ba9ca31c7a6 Mon Sep 17 00:00:00 2001
> From: Stephen Rothwell
> Date: Mon, 1 Jul 2019 14:55:02 +1000
> Subject: [PATCH] net/mlx5e: fix up for "linux/dim: Rename externally used
> net_dim members"
>
> Signed-off-by: Stephen Rothwell
> ---
> drivers/net/ethernet/mellanox/mlx5/core/en.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en.h
> b/drivers/net/ethernet/mellanox/mlx5/core/en.h
> index 9cebaa642727..f0d77eb66acf 100644
> --- a/drivers/net/ethernet/mellanox/mlx5/core/en.h
> +++ b/drivers/net/ethernet/mellanox/mlx5/core/en.h
> @@ -974,7 +974,7 @@ int mlx5e_open_xdpsq(struct mlx5e_channel *c, struct
> mlx5e_params *params,
> void mlx5e_close_xdpsq(struct mlx5e_xdpsq *sq);
>
> struct mlx5e_cq_param;
> -int mlx5e_open_cq(struct mlx5e_channel *c, struct net_dim_cq_moder moder,
> +int mlx5e_open_cq(struct mlx5e_channel *c, struct dim_cq_moder moder,
> struct mlx5e_cq_param *param, struct mlx5e_cq *cq);
> void mlx5e_close_cq(struct mlx5e_cq *cq);
>
Also, this:
drivers/net/ethernet/mellanox/mlx5/core/en/xsk/setup.c: In function
'mlx5e_open_xsk':
drivers/net/ethernet/mellanox/mlx5/core/en/xsk/setup.c:64:9: error: variable
'icocq_moder' has initializer but incomplete type
struct net_dim_cq_moder icocq_moder = {};
^~~~
drivers/net/ethernet/mellanox/mlx5/core/en/xsk/setup.c:64:26: error: storage
size of 'icocq_moder' isn't known
struct net_dim_cq_moder icocq_moder = {};
^~~
For which I applied this:
From: Stephen Rothwell
Date: Mon, 1 Jul 2019 15:00:08 +1000
Subject: [PATCH] another fix for "linux/dim: Rename externally used net_dim
members"
Signed-off-by: Stephen Rothwell
---
drivers/net/ethernet/mellanox/mlx5/core/en/xsk/setup.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en/xsk/setup.c
b/drivers/net/ethernet/mellanox/mlx5/core/en/xsk/setup.c
index 9b4d47c47c92..aaffa6f68dc0 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en/xsk/setup.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en/xsk/setup.c
@@ -61,7 +61,7 @@ int mlx5e_open_xsk(struct mlx5e_priv *priv, struct
mlx5e_params *params,
struct mlx5e_channel *c)
{
struct mlx5e_channel_param cparam = {};
- struct net_dim_cq_moder icocq_moder = {};
+ struct dim_cq_moder icocq_moder = {};
int err;
if (!mlx5e_validate_xsk_param(params, xsk, priv->mdev))
--
2.20.1
--
Cheers,
Stephen Rothwell
pgphOHurwSHmq.pgp
Description: OpenPGP digital signature
Re: linux-next: build failure after merge of the bpf-next tree
On Wed, Feb 27, 2019 at 5:31 PM Stephen Rothwell wrote:
>
> Hi all,
>
> After merging the bpf-next tree, today's linux-next build (arm
> multi_v7_defconfig) failed like this:
>
> kernel/sysctl.c:1238:13: error: 'sysctl_bpf_stats_enabled' undeclared here
> (not in a function); did you mean 'sysctl_base_table'?
>.data = _bpf_stats_enabled,
> ^~~~
> sysctl_base_table
>
> Caused by commit
>
> 492ecee892c2 ("bpf: enable program stats")
>
> CONFIG_BPF=y
> # CONFIG_BPF_SYSCALL is not set
>
> I applied the following patch for today, but it should be done
> properly. Also this patch leaves proc_dointvec_minmax_bpf_stats() as an
> unused function.
thanks for the report.
working on the fix.
Re: linux-next: build failure after merge of the bpf-next tree
On Wed, Dec 13, 2017 at 12:32:45PM +1100, Stephen Rothwell wrote:
> Hi all,
>
> After merging the bpf-next tree, today's linux-next build (arm
> multi_v7_defconfig) failed like this:
>
> kernel/events/core.o: In function `perf_ioctl':
> core.c:(.text+0x98c4): undefined reference to `bpf_event_query_prog_array'
>
> Caused by commit
>
> f371b304f12e ("bpf/tracing: allow user space to query prog array on the
> same tp")
>
> CONFIG_BPF_SYSCALL is not set for this build.
>
> I have used the bpf-next tree from next-20171212 for today.
Thanks for the report.
Yonghong, please take a look and send a followup fix based on bpf-next tree.
Re: linux-next: build failure after merge of the bpf-next tree
On Wed, Dec 13, 2017 at 12:32:45PM +1100, Stephen Rothwell wrote:
> Hi all,
>
> After merging the bpf-next tree, today's linux-next build (arm
> multi_v7_defconfig) failed like this:
>
> kernel/events/core.o: In function `perf_ioctl':
> core.c:(.text+0x98c4): undefined reference to `bpf_event_query_prog_array'
>
> Caused by commit
>
> f371b304f12e ("bpf/tracing: allow user space to query prog array on the
> same tp")
>
> CONFIG_BPF_SYSCALL is not set for this build.
>
> I have used the bpf-next tree from next-20171212 for today.
Thanks for the report.
Yonghong, please take a look and send a followup fix based on bpf-next tree.
