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

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

[Stephen Rothwell]

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.

-- 
Cheers,
Stephen Rothwell

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

[Alexei Starovoitov]

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.

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

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 618 bytes --]

Hi all,

After merging the bpf-next tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:

ERROR: ".xsk_reuseq_swap" [drivers/net/ethernet/intel/i40e/i40e.ko] undefined!
ERROR: ".xsk_reuseq_free" [drivers/net/ethernet/intel/i40e/i40e.ko] undefined!
ERROR: ".xsk_reuseq_prepare" [drivers/net/ethernet/intel/i40e/i40e.ko] undefined

Caused by commit

  9654bd10da60 ("i40e: clean zero-copy XDP Rx ring on shutdown/reset")

CONFIG_XDP_SOCKETS is not set for this build.

I have used the version of the bfp-next tree from next-20180906 for today.



-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Alexei Starovoitov]

On Fri, Sep 07, 2018 at 10:19:23AM +1000, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the bpf-next tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
> 
> ERROR: ".xsk_reuseq_swap" [drivers/net/ethernet/intel/i40e/i40e.ko] undefined!
> ERROR: ".xsk_reuseq_free" [drivers/net/ethernet/intel/i40e/i40e.ko] undefined!
> ERROR: ".xsk_reuseq_prepare" [drivers/net/ethernet/intel/i40e/i40e.ko] undefined
> 
> Caused by commit
> 
>   9654bd10da60 ("i40e: clean zero-copy XDP Rx ring on shutdown/reset")
> 
> CONFIG_XDP_SOCKETS is not set for this build.
> 
> I have used the version of the bfp-next tree from next-20180906 for today.

merge conflict and build error...
Bjorn, I'm thinking to toss the patches out of bpf-next and reapply
cleaned up version of the patches...
what do you think?

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

[Björn Töpel]

Den fre 7 sep. 2018 kl 02:23 skrev Alexei Starovoitov
<alexei.starovoitov@gmail.com>:
>
> On Fri, Sep 07, 2018 at 10:19:23AM +1000, Stephen Rothwell wrote:
> > Hi all,
> >
> > After merging the bpf-next tree, today's linux-next build (powerpc
> > ppc64_defconfig) failed like this:
> >
> > ERROR: ".xsk_reuseq_swap" [drivers/net/ethernet/intel/i40e/i40e.ko] undefined!
> > ERROR: ".xsk_reuseq_free" [drivers/net/ethernet/intel/i40e/i40e.ko] undefined!
> > ERROR: ".xsk_reuseq_prepare" [drivers/net/ethernet/intel/i40e/i40e.ko] undefined
> >
> > Caused by commit
> >
> >   9654bd10da60 ("i40e: clean zero-copy XDP Rx ring on shutdown/reset")
> >
> > CONFIG_XDP_SOCKETS is not set for this build.
> >
> > I have used the version of the bfp-next tree from next-20180906 for today.
>
> merge conflict and build error...
> Bjorn, I'm thinking to toss the patches out of bpf-next and reapply
> cleaned up version of the patches...
> what do you think?
>

Yes, do that. I'll get back with a cleaned up v2.


Thanks,
Björn

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

[Alexei Starovoitov]

On Fri, Sep 07, 2018 at 07:21:05AM +0200, Björn Töpel wrote:
> Den fre 7 sep. 2018 kl 02:23 skrev Alexei Starovoitov
> <alexei.starovoitov@gmail.com>:
> >
> > On Fri, Sep 07, 2018 at 10:19:23AM +1000, Stephen Rothwell wrote:
> > > Hi all,
> > >
> > > After merging the bpf-next tree, today's linux-next build (powerpc
> > > ppc64_defconfig) failed like this:
> > >
> > > ERROR: ".xsk_reuseq_swap" [drivers/net/ethernet/intel/i40e/i40e.ko] undefined!
> > > ERROR: ".xsk_reuseq_free" [drivers/net/ethernet/intel/i40e/i40e.ko] undefined!
> > > ERROR: ".xsk_reuseq_prepare" [drivers/net/ethernet/intel/i40e/i40e.ko] undefined
> > >
> > > Caused by commit
> > >
> > >   9654bd10da60 ("i40e: clean zero-copy XDP Rx ring on shutdown/reset")
> > >
> > > CONFIG_XDP_SOCKETS is not set for this build.
> > >
> > > I have used the version of the bfp-next tree from next-20180906 for today.
> >
> > merge conflict and build error...
> > Bjorn, I'm thinking to toss the patches out of bpf-next and reapply
> > cleaned up version of the patches...
> > what do you think?
> >
> 
> Yes, do that. I'll get back with a cleaned up v2.

Done.

Unfortunately during interactive rebase that removed your commits git didn't
preserve merge commits that came after yours,
so Jesper's and Yonghong's cover letters are not in the git history.
Yet all patches are in the same order.
Explicit revert with trail in the git history would have been worse.
patchworks + git isn't the most convenient workflow. sigh.

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

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 484 bytes --]

Hi all,

After merging the bpf-next tree, today's linux-next build (x86_64
allmodconfig) failed like this:

x86_64-linux-gnu-ld: net/core/filter.o: in function `sk_lookup':
(.text+0x19219): undefined reference to `__udp6_lib_lookup'

Caused by commit

  6acc9b432e67 ("bpf: Add helper to retrieve socket in BPF")

I assume that __udp6_lib_lookup ended up in the IPv6 module.

I used the bpf-next tree from next-20181002 for today.



-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Joe Stringer]

On Tue, 2 Oct 2018 at 20:19, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Hi all,
>
> After merging the bpf-next tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> x86_64-linux-gnu-ld: net/core/filter.o: in function `sk_lookup':
> (.text+0x19219): undefined reference to `__udp6_lib_lookup'
>
> Caused by commit
>
>   6acc9b432e67 ("bpf: Add helper to retrieve socket in BPF")
>
> I assume that __udp6_lib_lookup ended up in the IPv6 module.
>
> I used the bpf-next tree from next-20181002 for today.

My mistake, will send out a fix shortly.

Cheers,
Joe

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

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1535 bytes --]

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  = &sysctl_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.

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Thu, 28 Feb 2019 12:26:58 +1100
Subject: [PATCH] bpf: hack to make "enable program stats" build

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 kernel/sysctl.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/sysctl.c b/kernel/sysctl.c
index 86e0771352f2..80a70f69cbd5 100644
--- a/kernel/sysctl.c
+++ b/kernel/sysctl.c
@@ -1232,7 +1232,6 @@ static struct ctl_table kern_table[] = {
 		.extra1		= &one,
 		.extra2		= &one,
 	},
-#endif
 	{
 		.procname	= "bpf_stats_enabled",
 		.data		= &sysctl_bpf_stats_enabled,
@@ -1242,6 +1241,7 @@ static struct ctl_table kern_table[] = {
 		.extra1		= &zero,
 		.extra2		= &one,
 	},
+#endif
 #if defined(CONFIG_TREE_RCU) || defined(CONFIG_PREEMPT_RCU)
 	{
 		.procname	= "panic_on_rcu_stall",
-- 
2.20.1

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Alexei Starovoitov]

On Wed, Feb 27, 2019 at 5:31 PM Stephen Rothwell <sfr@canb.auug.org.au> 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  = &sysctl_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.

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

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1526 bytes --]

Hi all,

After merging the bpf-next tree, today's linux-next build (powerpc perf)
failed like this:

In file included from xsk.c:32:
libbpf_util.h:49:3: error: #warning Architecture missing native barrier functions in libbpf_util.h. [-Werror=cpp]
 # warning Architecture missing native barrier functions in libbpf_util.h.
   ^~~~~~~
cc1: all warnings being treated as errors

Caused by commit

  b7e3a28019c9 ("libbpf: remove dependency on barrier.h in xsk.h")

I have applied the following patch for today ... please fix this.

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Thu, 18 Apr 2019 11:54:56 +1000
Subject: [PATCH] suppress warning in tools/lib/bpf/libbpf_util.h

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 tools/lib/bpf/libbpf_util.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/lib/bpf/libbpf_util.h b/tools/lib/bpf/libbpf_util.h
index 172b707e007b..a54eb2cdbdd6 100644
--- a/tools/lib/bpf/libbpf_util.h
+++ b/tools/lib/bpf/libbpf_util.h
@@ -46,7 +46,7 @@ do {				\
 # define libbpf_smp_mb() asm volatile("dmb ish" : : : "memory")
 # define libbpf_smp_rwmb() libbpf_smp_mb()
 #else
-# warning Architecture missing native barrier functions in libbpf_util.h.
+//# warning Architecture missing native barrier functions in libbpf_util.h.
 # define libbpf_smp_rmb() __sync_synchronize()
 # define libbpf_smp_wmb() __sync_synchronize()
 # define libbpf_smp_mb() __sync_synchronize()
-- 
2.20.1

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1989 bytes --]

Hi all,

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 <sfr@canb.auug.org.au>
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 <sfr@canb.auug.org.au>
---
 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);
 
-- 
2.20.1



-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 3664 bytes --]

Hi all,

On Mon, 1 Jul 2019 14:57:22 +1000 Stephen Rothwell <sfr@canb.auug.org.au> 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 <sfr@canb.auug.org.au>
> 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 <sfr@canb.auug.org.au>
> ---
>  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 <sfr@canb.auug.org.au>
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 <sfr@canb.auug.org.au>
---
 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

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 441 bytes --]

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.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Jiri Olsa]

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

[Jiri Olsa]

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

[Geert Uytterhoeven]

Hi Jiri,

On Tue, Jul 14, 2020 at 10:33 AM Jiri Olsa <jolsa@redhat.com> 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 <geert+renesas@glider.be>

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@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

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

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 701 bytes --]

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.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 878 bytes --]

Hi all,

On Fri, 21 Aug 2020 11:11:11 +1000 Stephen Rothwell <sfr@canb.auug.org.au> 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

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Alexei Starovoitov]

On Mon, Aug 24, 2020 at 6:20 PM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Hi all,
>
> On Fri, 21 Aug 2020 11:11:11 +1000 Stephen Rothwell <sfr@canb.auug.org.au> 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

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1498 bytes --]

Hi Alexei,

On Mon, 24 Aug 2020 18:25:44 -0700 Alexei Starovoitov <alexei.starovoitov@gmail.com> wrote:
>
> On Mon, Aug 24, 2020 at 6:20 PM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > On Fri, 21 Aug 2020 11:11:11 +1000 Stephen Rothwell <sfr@canb.auug.org.au> 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

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Alexei Starovoitov]

On Mon, Aug 24, 2020 at 8:04 PM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Hi Alexei,
>
> On Mon, 24 Aug 2020 18:25:44 -0700 Alexei Starovoitov <alexei.starovoitov@gmail.com> wrote:
> >
> > On Mon, Aug 24, 2020 at 6:20 PM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > >
> > > On Fri, 21 Aug 2020 11:11:11 +1000 Stephen Rothwell <sfr@canb.auug.org.au> 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

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1181 bytes --]

Hi Alexei,

On Mon, 24 Aug 2020 20:27:28 -0700 Alexei Starovoitov <alexei.starovoitov@gmail.com> 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

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Alexei Starovoitov]

On Mon, Aug 24, 2020 at 11:50 PM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Hi Alexei,
>
> On Mon, 24 Aug 2020 20:27:28 -0700 Alexei Starovoitov <alexei.starovoitov@gmail.com> 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

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 399 bytes --]

Hi Alexei,

On Tue, 25 Aug 2020 07:33:51 -0700 Alexei Starovoitov <alexei.starovoitov@gmail.com> 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

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Alexei Starovoitov]

On Tue, Aug 25, 2020 at 2:10 PM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Hi Alexei,
>
> On Tue, 25 Aug 2020 07:33:51 -0700 Alexei Starovoitov <alexei.starovoitov@gmail.com> 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

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 823 bytes --]

Hi Alexei,

On Tue, 25 Aug 2020 15:34:52 -0700 Alexei Starovoitov <alexei.starovoitov@gmail.com> wrote:
>
> On Tue, Aug 25, 2020 at 2:10 PM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > Hi Alexei,
> >
> > On Tue, 25 Aug 2020 07:33:51 -0700 Alexei Starovoitov <alexei.starovoitov@gmail.com> 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

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1460 bytes --]

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.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Andrii Nakryiko]

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!

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

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1574 bytes --]

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")

sk_buff only has a napi_id if defined(CONFIG_NET_RX_BUSY_POLL) ||
defined(CONFIG_XPS).

I have applied the following patch for today.

From bd2a1a4a773c1f306460b4309b12cad245a5edad Mon Sep 17 00:00:00 2001
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Tue, 1 Dec 2020 19:02:58 +1100
Subject: [PATCH] fix for "xsk: Propagate napi_id to XDP socket Rx path"

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 include/net/busy_poll.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/include/net/busy_poll.h b/include/net/busy_poll.h
index 45b3e04b99d3..07a88f592e72 100644
--- a/include/net/busy_poll.h
+++ b/include/net/busy_poll.h
@@ -147,7 +147,9 @@ static inline void __sk_mark_napi_id_once_xdp(struct sock *sk, unsigned int napi
 static inline void sk_mark_napi_id_once(struct sock *sk,
 					const struct sk_buff *skb)
 {
+#ifdef CONFIG_NET_RX_BUSY_POLL
 	__sk_mark_napi_id_once_xdp(sk, skb->napi_id);
+#endif
 }
 
 static inline void sk_mark_napi_id_once_xdp(struct sock *sk,
-- 
2.29.2

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Daniel Borkmann]

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!

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

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 398 bytes --]

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.

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.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Björn Töpel]

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_jvpuntovUQ8w@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

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1030 bytes --]

Hi Björn,

[Cc'ing a few (maybe) interested parties]

On Thu, 11 Mar 2021 07:47:03 +0100 Björn Töpel <bjorn.topel@intel.com> 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_jvpuntovUQ8w@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

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1243 bytes --]

Hi all,

On Fri, 12 Mar 2021 12:00:14 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> [Cc'ing a few (maybe) interested parties]
> 
> On Thu, 11 Mar 2021 07:47:03 +0100 Björn Töpel <bjorn.topel@intel.com> 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_jvpuntovUQ8w@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

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 943 bytes --]

Hi all,

After merging the bpf-next tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:

kernel/trace/bpf_trace.c:717:47: error: expected ')' before 'struct'
  717 | BTF_ID_LIST_GLOBAL_SINGLE(btf_task_struct_ids, struct, task_struct)
      |                                               ^~~~~~~
      |                                               )
kernel/trace/bpf_trace.c: In function 'bpf_tracing_func_proto':
kernel/trace/bpf_trace.c:1051:11: error: 'bpf_get_current_task_btf_proto' undeclared (first use in this function); did you mean 'bpf_get_current_task_proto'?
 1051 |   return &bpf_get_current_task_btf_proto;
      |           ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      |           bpf_get_current_task_proto

Caused by commit

  33c5cb36015a ("bpf: Consolidate task_struct BTF_ID declarations")

I have used the bpf-next tree from next-20210825 for today.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Daniel Xu]

Hi Stephen,

On Thu, Aug 26, 2021 at 11:50:50AM +1000, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the bpf-next tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
> 
> kernel/trace/bpf_trace.c:717:47: error: expected ')' before 'struct'
>   717 | BTF_ID_LIST_GLOBAL_SINGLE(btf_task_struct_ids, struct, task_struct)
>       |                                               ^~~~~~~
>       |                                               )
> kernel/trace/bpf_trace.c: In function 'bpf_tracing_func_proto':
> kernel/trace/bpf_trace.c:1051:11: error: 'bpf_get_current_task_btf_proto' undeclared (first use in this function); did you mean 'bpf_get_current_task_proto'?
>  1051 |   return &bpf_get_current_task_btf_proto;
>       |           ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>       |           bpf_get_current_task_proto
> 
> Caused by commit
> 
>   33c5cb36015a ("bpf: Consolidate task_struct BTF_ID declarations")
> 
> I have used the bpf-next tree from next-20210825 for today.

Sorry about the breakage. I've put up
https://lore.kernel.org/bpf/05d94748d9f4b3eecedc4fddd6875418a396e23c.1629942444.git.dxu@dxuuu.xyz/T/#u
which I think should fix it. Can you give that patch a try?

Thanks,
Daniel

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

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 865 bytes --]

Hi all,

After merging the bpf-next tree, today's linux-next build (perf) failed
like this:

util/bpf-event.c: In function 'btf__load_from_kernel_by_id':
util/bpf-event.c:27:8: error: 'btf__get_from_id' is deprecated: libbpf v0.6+: use btf__load_from_kernel_by_id instead [-Werror=deprecated-declarations]
   27 |        int err = btf__get_from_id(id, &btf);
      |        ^~~
In file included from util/bpf-event.c:5:
/home/sfr/next/next/tools/lib/bpf/btf.h:54:16: note: declared here
   54 | LIBBPF_API int btf__get_from_id(__u32 id, struct btf **btf);
      |                ^~~~~~~~~~~~~~~~
cc1: all warnings being treated as errors

Caused by commit

  0b46b7550560 ("libbpf: Add LIBBPF_DEPRECATED_SINCE macro for scheduling API deprecations")

I have used the bpf-next tree from next-20210913 for today.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Andrii Nakryiko]

On Mon, Sep 13, 2021 at 6:37 PM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Hi all,
>
> After merging the bpf-next tree, today's linux-next build (perf) failed
> like this:
>
> util/bpf-event.c: In function 'btf__load_from_kernel_by_id':
> util/bpf-event.c:27:8: error: 'btf__get_from_id' is deprecated: libbpf v0.6+: use btf__load_from_kernel_by_id instead [-Werror=deprecated-declarations]
>    27 |        int err = btf__get_from_id(id, &btf);
>       |        ^~~
> In file included from util/bpf-event.c:5:
> /home/sfr/next/next/tools/lib/bpf/btf.h:54:16: note: declared here
>    54 | LIBBPF_API int btf__get_from_id(__u32 id, struct btf **btf);
>       |                ^~~~~~~~~~~~~~~~
> cc1: all warnings being treated as errors
>
> Caused by commit
>
>   0b46b7550560 ("libbpf: Add LIBBPF_DEPRECATED_SINCE macro for scheduling API deprecations")

Should be fixed by [0], when applied to perf tree. Thanks for reporting!

  [0] https://patchwork.kernel.org/project/netdevbpf/patch/20210914170004.4185659-1-andrii@kernel.org/

>
> I have used the bpf-next tree from next-20210913 for today.
>
> --
> Cheers,
> Stephen Rothwell

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

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1332 bytes --]

Hi Andrii,

On Tue, 14 Sep 2021 16:25:55 -0700 Andrii Nakryiko <andrii.nakryiko@gmail.com> wrote:
>
> On Mon, Sep 13, 2021 at 6:37 PM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > After merging the bpf-next tree, today's linux-next build (perf) failed
> > like this:
> >
> > util/bpf-event.c: In function 'btf__load_from_kernel_by_id':
> > util/bpf-event.c:27:8: error: 'btf__get_from_id' is deprecated: libbpf v0.6+: use btf__load_from_kernel_by_id instead [-Werror=deprecated-declarations]
> >    27 |        int err = btf__get_from_id(id, &btf);
> >       |        ^~~
> > In file included from util/bpf-event.c:5:
> > /home/sfr/next/next/tools/lib/bpf/btf.h:54:16: note: declared here
> >    54 | LIBBPF_API int btf__get_from_id(__u32 id, struct btf **btf);
> >       |                ^~~~~~~~~~~~~~~~
> > cc1: all warnings being treated as errors
> >
> > Caused by commit
> >
> >   0b46b7550560 ("libbpf: Add LIBBPF_DEPRECATED_SINCE macro for scheduling API deprecations")  
> 
> Should be fixed by [0], when applied to perf tree. Thanks for reporting!
> 
>   [0] https://patchwork.kernel.org/project/netdevbpf/patch/20210914170004.4185659-1-andrii@kernel.org/

That really needs to be applied to the bpf-next tree (presumably with
the appropriate Acks).

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Andrii Nakryiko]

On Tue, Sep 14, 2021 at 4:38 PM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Hi Andrii,
>
> On Tue, 14 Sep 2021 16:25:55 -0700 Andrii Nakryiko <andrii.nakryiko@gmail.com> wrote:
> >
> > On Mon, Sep 13, 2021 at 6:37 PM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > >
> > > After merging the bpf-next tree, today's linux-next build (perf) failed
> > > like this:
> > >
> > > util/bpf-event.c: In function 'btf__load_from_kernel_by_id':
> > > util/bpf-event.c:27:8: error: 'btf__get_from_id' is deprecated: libbpf v0.6+: use btf__load_from_kernel_by_id instead [-Werror=deprecated-declarations]
> > >    27 |        int err = btf__get_from_id(id, &btf);
> > >       |        ^~~
> > > In file included from util/bpf-event.c:5:
> > > /home/sfr/next/next/tools/lib/bpf/btf.h:54:16: note: declared here
> > >    54 | LIBBPF_API int btf__get_from_id(__u32 id, struct btf **btf);
> > >       |                ^~~~~~~~~~~~~~~~
> > > cc1: all warnings being treated as errors
> > >
> > > Caused by commit
> > >
> > >   0b46b7550560 ("libbpf: Add LIBBPF_DEPRECATED_SINCE macro for scheduling API deprecations")
> >
> > Should be fixed by [0], when applied to perf tree. Thanks for reporting!
> >
> >   [0] https://patchwork.kernel.org/project/netdevbpf/patch/20210914170004.4185659-1-andrii@kernel.org/
>
> That really needs to be applied to the bpf-next tree (presumably with
> the appropriate Acks).
>

This is perf code that's not in bpf-next yet.


> --
> Cheers,
> Stephen Rothwell

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

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1924 bytes --]

Hi Andrii,

On Tue, 14 Sep 2021 16:40:37 -0700 Andrii Nakryiko <andrii.nakryiko@gmail.com> wrote:
>
> On Tue, Sep 14, 2021 at 4:38 PM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > Hi Andrii,
> >
> > On Tue, 14 Sep 2021 16:25:55 -0700 Andrii Nakryiko <andrii.nakryiko@gmail.com> wrote:  
> > >
> > > On Mon, Sep 13, 2021 at 6:37 PM Stephen Rothwell <sfr@canb.auug.org.au> wrote:  
> > > >
> > > > After merging the bpf-next tree, today's linux-next build (perf) failed
> > > > like this:
> > > >
> > > > util/bpf-event.c: In function 'btf__load_from_kernel_by_id':
> > > > util/bpf-event.c:27:8: error: 'btf__get_from_id' is deprecated: libbpf v0.6+: use btf__load_from_kernel_by_id instead [-Werror=deprecated-declarations]
> > > >    27 |        int err = btf__get_from_id(id, &btf);
> > > >       |        ^~~
> > > > In file included from util/bpf-event.c:5:
> > > > /home/sfr/next/next/tools/lib/bpf/btf.h:54:16: note: declared here
> > > >    54 | LIBBPF_API int btf__get_from_id(__u32 id, struct btf **btf);
> > > >       |                ^~~~~~~~~~~~~~~~
> > > > cc1: all warnings being treated as errors
> > > >
> > > > Caused by commit
> > > >
> > > >   0b46b7550560 ("libbpf: Add LIBBPF_DEPRECATED_SINCE macro for scheduling API deprecations")  
> > >
> > > Should be fixed by [0], when applied to perf tree. Thanks for reporting!
> > >
> > >   [0] https://patchwork.kernel.org/project/netdevbpf/patch/20210914170004.4185659-1-andrii@kernel.org/  
> >
> > That really needs to be applied to the bpf-next tree (presumably with
> > the appropriate Acks).
> >  
> 
> This is perf code that's not in bpf-next yet.

Then you need to think of a solution for the bpf-next tree, as it will
not build (allmodconfig) when combined with Linus' current tree.  And
when it is merged into the net-next tree, that tree will be broken as
well.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Alexei Starovoitov]

On Tue, Sep 14, 2021 at 4:59 PM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Hi Andrii,
>
> On Tue, 14 Sep 2021 16:40:37 -0700 Andrii Nakryiko <andrii.nakryiko@gmail.com> wrote:
> >
> > On Tue, Sep 14, 2021 at 4:38 PM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > >
> > > Hi Andrii,
> > >
> > > On Tue, 14 Sep 2021 16:25:55 -0700 Andrii Nakryiko <andrii.nakryiko@gmail.com> wrote:
> > > >
> > > > On Mon, Sep 13, 2021 at 6:37 PM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > > > >
> > > > > After merging the bpf-next tree, today's linux-next build (perf) failed
> > > > > like this:
> > > > >
> > > > > util/bpf-event.c: In function 'btf__load_from_kernel_by_id':
> > > > > util/bpf-event.c:27:8: error: 'btf__get_from_id' is deprecated: libbpf v0.6+: use btf__load_from_kernel_by_id instead [-Werror=deprecated-declarations]
> > > > >    27 |        int err = btf__get_from_id(id, &btf);
> > > > >       |        ^~~
> > > > > In file included from util/bpf-event.c:5:
> > > > > /home/sfr/next/next/tools/lib/bpf/btf.h:54:16: note: declared here
> > > > >    54 | LIBBPF_API int btf__get_from_id(__u32 id, struct btf **btf);
> > > > >       |                ^~~~~~~~~~~~~~~~
> > > > > cc1: all warnings being treated as errors
> > > > >
> > > > > Caused by commit
> > > > >
> > > > >   0b46b7550560 ("libbpf: Add LIBBPF_DEPRECATED_SINCE macro for scheduling API deprecations")
> > > >
> > > > Should be fixed by [0], when applied to perf tree. Thanks for reporting!
> > > >
> > > >   [0] https://patchwork.kernel.org/project/netdevbpf/patch/20210914170004.4185659-1-andrii@kernel.org/
> > >
> > > That really needs to be applied to the bpf-next tree (presumably with
> > > the appropriate Acks).
> > >
> >
> > This is perf code that's not in bpf-next yet.
>
> Then you need to think of a solution for the bpf-next tree, as it will
> not build (allmodconfig) when combined with Linus' current tree.  And
> when it is merged into the net-next tree, that tree will be broken as
> well.

It's not a problem of bpf-tree and it cannot be fixed in bpf-tree.
The bug is in perf tree.

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

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 7545 bytes --]

Hi all,

After merging the bpf-next tree, today's linux-next build (native perf)
failed like this:

tests/bpf.c: In function 'check_env':
tests/bpf.c:299:2: error: 'bpf_load_program' is deprecated: libbpf v0.7+: use bpf_prog_load() instead [-Werror=deprecated-declarations]
  299 |  err = bpf_load_program(BPF_PROG_TYPE_KPROBE, insns,
      |  ^~~
In file included from tests/bpf.c:28:
tools/lib/bpf/bpf.h:204:16: note: declared here
  204 | LIBBPF_API int bpf_load_program(enum bpf_prog_type type,
      |                ^~~~~~~~~~~~~~~~
cc1: all warnings being treated as errors
util/bpf-loader.c: In function 'bpf__clear':
util/bpf-loader.c:115:2: error: 'bpf_object__next' is deprecated: libbpf v0.7+: track bpf_objects in application code instead [-Werror=deprecated-declarations]
  115 |  bpf_object__for_each_safe(obj, tmp) {
      |  ^~~~~~~~~~~~~~~~~~~~~~~~~
In file included from util/bpf-loader.c:10:
tools/lib/bpf/libbpf.h:176:20: note: declared here
  176 | struct bpf_object *bpf_object__next(struct bpf_object *prev);
      |                    ^~~~~~~~~~~~~~~~
util/bpf-loader.c:115:2: error: 'bpf_object__next' is deprecated: libbpf v0.7+: track bpf_objects in application code instead [-Werror=deprecated-declarations]
  115 |  bpf_object__for_each_safe(obj, tmp) {
      |  ^~~~~~~~~~~~~~~~~~~~~~~~~
In file included from util/bpf-loader.c:10:
tools/lib/bpf/libbpf.h:176:20: note: declared here
  176 | struct bpf_object *bpf_object__next(struct bpf_object *prev);
      |                    ^~~~~~~~~~~~~~~~
util/bpf-loader.c:115:2: error: 'bpf_object__next' is deprecated: libbpf v0.7+: track bpf_objects in application code instead [-Werror=deprecated-declarations]
  115 |  bpf_object__for_each_safe(obj, tmp) {
      |  ^~~~~~~~~~~~~~~~~~~~~~~~~
In file included from util/bpf-loader.c:10:
tools/lib/bpf/libbpf.h:176:20: note: declared here
  176 | struct bpf_object *bpf_object__next(struct bpf_object *prev);
      |                    ^~~~~~~~~~~~~~~~
util/bpf-loader.c: In function 'hook_load_preprocessor':
util/bpf-loader.c:621:2: error: 'bpf_program__set_prep' is deprecated: libbpf v0.7+: use bpf_program__insns() for getting bpf_program instructions [-Werror=deprecated-declarations]
  621 |  err = bpf_program__set_prep(prog, priv->nr_types,
      |  ^~~
In file included from util/bpf-loader.c:10:
tools/lib/bpf/libbpf.h:467:16: note: declared here
  467 | LIBBPF_API int bpf_program__set_prep(struct bpf_program *prog, int nr_instance,
      |                ^~~~~~~~~~~~~~~~~~~~~
util/bpf-loader.c: In function 'bpf__foreach_event':
util/bpf-loader.c:776:5: error: 'bpf_program__nth_fd' is deprecated: libbpf v0.7+: multi-instance bpf_program support is deprecated [-Werror=deprecated-declarations]
  776 |     fd = bpf_program__nth_fd(prog, type);
      |     ^~
In file included from util/bpf-loader.c:10:
tools/lib/bpf/libbpf.h:471:16: note: declared here
  471 | LIBBPF_API int bpf_program__nth_fd(const struct bpf_program *prog, int n);
      |                ^~~~~~~~~~~~~~~~~~~
util/bpf-loader.c: In function 'bpf__apply_obj_config':
util/bpf-loader.c:1501:2: error: 'bpf_object__next' is deprecated: libbpf v0.7+: track bpf_objects in application code instead [-Werror=deprecated-declarations]
 1501 |  bpf_object__for_each_safe(obj, tmp) {
      |  ^~~~~~~~~~~~~~~~~~~~~~~~~
In file included from util/bpf-loader.c:10:
tools/lib/bpf/libbpf.h:176:20: note: declared here
  176 | struct bpf_object *bpf_object__next(struct bpf_object *prev);
      |                    ^~~~~~~~~~~~~~~~
util/bpf-loader.c:1501:2: error: 'bpf_object__next' is deprecated: libbpf v0.7+: track bpf_objects in application code instead [-Werror=deprecated-declarations]
 1501 |  bpf_object__for_each_safe(obj, tmp) {
      |  ^~~~~~~~~~~~~~~~~~~~~~~~~
In file included from util/bpf-loader.c:10:
tools/lib/bpf/libbpf.h:176:20: note: declared here
  176 | struct bpf_object *bpf_object__next(struct bpf_object *prev);
      |                    ^~~~~~~~~~~~~~~~
util/bpf-loader.c:1501:2: error: 'bpf_object__next' is deprecated: libbpf v0.7+: track bpf_objects in application code instead [-Werror=deprecated-declarations]
 1501 |  bpf_object__for_each_safe(obj, tmp) {
      |  ^~~~~~~~~~~~~~~~~~~~~~~~~
In file included from util/bpf-loader.c:10:
tools/lib/bpf/libbpf.h:176:20: note: declared here
  176 | struct bpf_object *bpf_object__next(struct bpf_object *prev);
      |                    ^~~~~~~~~~~~~~~~
util/bpf-loader.c: In function 'bpf__setup_output_event':
util/bpf-loader.c:1529:2: error: 'bpf_object__next' is deprecated: libbpf v0.7+: track bpf_objects in application code instead [-Werror=deprecated-declarations]
 1529 |  bpf__for_each_map_named(map, obj, tmp, name) {
      |  ^~~~~~~~~~~~~~~~~~~~~~~
In file included from util/bpf-loader.c:10:
tools/lib/bpf/libbpf.h:176:20: note: declared here
  176 | struct bpf_object *bpf_object__next(struct bpf_object *prev);
      |                    ^~~~~~~~~~~~~~~~
util/bpf-loader.c:1529:2: error: 'bpf_object__next' is deprecated: libbpf v0.7+: track bpf_objects in application code instead [-Werror=deprecated-declarations]
 1529 |  bpf__for_each_map_named(map, obj, tmp, name) {
      |  ^~~~~~~~~~~~~~~~~~~~~~~
In file included from util/bpf-loader.c:10:
tools/lib/bpf/libbpf.h:176:20: note: declared here
  176 | struct bpf_object *bpf_object__next(struct bpf_object *prev);
      |                    ^~~~~~~~~~~~~~~~
util/bpf-loader.c:1529:2: error: 'bpf_object__next' is deprecated: libbpf v0.7+: track bpf_objects in application code instead [-Werror=deprecated-declarations]
 1529 |  bpf__for_each_map_named(map, obj, tmp, name) {
      |  ^~~~~~~~~~~~~~~~~~~~~~~
In file included from util/bpf-loader.c:10:
tools/lib/bpf/libbpf.h:176:20: note: declared here
  176 | struct bpf_object *bpf_object__next(struct bpf_object *prev);
      |                    ^~~~~~~~~~~~~~~~
util/bpf-loader.c:1565:2: error: 'bpf_object__next' is deprecated: libbpf v0.7+: track bpf_objects in application code instead [-Werror=deprecated-declarations]
 1565 |  bpf__for_each_map_named(map, obj, tmp, name) {
      |  ^~~~~~~~~~~~~~~~~~~~~~~
In file included from util/bpf-loader.c:10:
tools/lib/bpf/libbpf.h:176:20: note: declared here
  176 | struct bpf_object *bpf_object__next(struct bpf_object *prev);
      |                    ^~~~~~~~~~~~~~~~
util/bpf-loader.c:1565:2: error: 'bpf_object__next' is deprecated: libbpf v0.7+: track bpf_objects in application code instead [-Werror=deprecated-declarations]
 1565 |  bpf__for_each_map_named(map, obj, tmp, name) {
      |  ^~~~~~~~~~~~~~~~~~~~~~~
In file included from util/bpf-loader.c:10:
tools/lib/bpf/libbpf.h:176:20: note: declared here
  176 | struct bpf_object *bpf_object__next(struct bpf_object *prev);
      |                    ^~~~~~~~~~~~~~~~
util/bpf-loader.c:1565:2: error: 'bpf_object__next' is deprecated: libbpf v0.7+: track bpf_objects in application code instead [-Werror=deprecated-declarations]
 1565 |  bpf__for_each_map_named(map, obj, tmp, name) {
      |  ^~~~~~~~~~~~~~~~~~~~~~~
In file included from util/bpf-loader.c:10:
tools/lib/bpf/libbpf.h:176:20: note: declared here
  176 | struct bpf_object *bpf_object__next(struct bpf_object *prev);
      |                    ^~~~~~~~~~~~~~~~
cc1: all warnings being treated as errors

I am not sure what caused this, but I have just used the bpf-next tree
from next-20211202 for today.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 484 bytes --]

Hi all,

After merging the bpf-next tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:

kernel/bpf/core.c:830:23: error: variably modified 'bitmap' at file scope
  830 |         unsigned long bitmap[BITS_TO_LONGS(BPF_PROG_CHUNK_COUNT)];
      |                       ^~~~~~

Caused by commit

  57631054fae6 ("bpf: Introduce bpf_prog_pack allocator")

I have used the bpf-next tree from next-20220208 for today.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1807 bytes --]

Hi all,

After merging the bpf-next tree, today's linux-next build
(x86_64 allmodconfig) failed like this:

In file included from include/linux/compiler_types.h:73,
                 from <command-line>:
drivers/net/ethernet/intel/i40e/i40e_xsk.c: In function 'i40e_run_xdp_zc':
include/linux/compiler_attributes.h:222:41: error: attribute 'fallthrough' not preceding a case label or default label [-Werror]
  222 | # define fallthrough                    __attribute__((__fallthrough__))
      |                                         ^~~~~~~~~~~~~
drivers/net/ethernet/intel/i40e/i40e_xsk.c:192:17: note: in expansion of macro 'fallthrough'
  192 |                 fallthrough; /* handle aborts by dropping packet */
      |                 ^~~~~~~~~~~
cc1: all warnings being treated as errors
In file included from include/linux/compiler_types.h:73,
                 from <command-line>:
drivers/net/ethernet/intel/ixgbe/ixgbe_xsk.c: In function 'ixgbe_run_xdp_zc':
include/linux/compiler_attributes.h:222:41: error: attribute 'fallthrough' not preceding a case label or default label [-Werror]
  222 | # define fallthrough                    __attribute__((__fallthrough__))
      |                                         ^~~~~~~~~~~~~
drivers/net/ethernet/intel/ixgbe/ixgbe_xsk.c:147:17: note: in expansion of macro 'fallthrough'
  147 |                 fallthrough; /* handle aborts by dropping packet */
      |                 ^~~~~~~~~~~
cc1: all warnings being treated as errors

Caused by commits

  b8aef650e549 ("i40e, xsk: Terminate Rx side of NAPI when XSK Rx queue gets full")
  c7dd09fd4628 ("ixgbe, xsk: Terminate Rx side of NAPI when XSK Rx queue gets full")

I have used the bpf-next tree from next-20220414 for today.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1994 bytes --]

Hi all,

On Tue, 19 Apr 2022 11:56:20 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> After merging the bpf-next tree, today's linux-next build
> (x86_64 allmodconfig) failed like this:
> 
> In file included from include/linux/compiler_types.h:73,
>                  from <command-line>:
> drivers/net/ethernet/intel/i40e/i40e_xsk.c: In function 'i40e_run_xdp_zc':
> include/linux/compiler_attributes.h:222:41: error: attribute 'fallthrough' not preceding a case label or default label [-Werror]
>   222 | # define fallthrough                    __attribute__((__fallthrough__))
>       |                                         ^~~~~~~~~~~~~
> drivers/net/ethernet/intel/i40e/i40e_xsk.c:192:17: note: in expansion of macro 'fallthrough'
>   192 |                 fallthrough; /* handle aborts by dropping packet */
>       |                 ^~~~~~~~~~~
> cc1: all warnings being treated as errors
> In file included from include/linux/compiler_types.h:73,
>                  from <command-line>:
> drivers/net/ethernet/intel/ixgbe/ixgbe_xsk.c: In function 'ixgbe_run_xdp_zc':
> include/linux/compiler_attributes.h:222:41: error: attribute 'fallthrough' not preceding a case label or default label [-Werror]
>   222 | # define fallthrough                    __attribute__((__fallthrough__))
>       |                                         ^~~~~~~~~~~~~
> drivers/net/ethernet/intel/ixgbe/ixgbe_xsk.c:147:17: note: in expansion of macro 'fallthrough'
>   147 |                 fallthrough; /* handle aborts by dropping packet */
>       |                 ^~~~~~~~~~~
> cc1: all warnings being treated as errors
> 
> Caused by commits
> 
>   b8aef650e549 ("i40e, xsk: Terminate Rx side of NAPI when XSK Rx queue gets full")
>   c7dd09fd4628 ("ixgbe, xsk: Terminate Rx side of NAPI when XSK Rx queue gets full")
> 
> I have used the bpf-next tree from next-20220414 for today.

I am still getting these failures ...

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Daniel Borkmann]

On 4/21/22 2:32 AM, Stephen Rothwell wrote:
> Hi all,

Maciej, I presume you are already working on a follow-up for the below?

> On Tue, 19 Apr 2022 11:56:20 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>>
>> After merging the bpf-next tree, today's linux-next build
>> (x86_64 allmodconfig) failed like this:
>>
>> In file included from include/linux/compiler_types.h:73,
>>                   from <command-line>:
>> drivers/net/ethernet/intel/i40e/i40e_xsk.c: In function 'i40e_run_xdp_zc':
>> include/linux/compiler_attributes.h:222:41: error: attribute 'fallthrough' not preceding a case label or default label [-Werror]
>>    222 | # define fallthrough                    __attribute__((__fallthrough__))
>>        |                                         ^~~~~~~~~~~~~
>> drivers/net/ethernet/intel/i40e/i40e_xsk.c:192:17: note: in expansion of macro 'fallthrough'
>>    192 |                 fallthrough; /* handle aborts by dropping packet */
>>        |                 ^~~~~~~~~~~
>> cc1: all warnings being treated as errors
>> In file included from include/linux/compiler_types.h:73,
>>                   from <command-line>:
>> drivers/net/ethernet/intel/ixgbe/ixgbe_xsk.c: In function 'ixgbe_run_xdp_zc':
>> include/linux/compiler_attributes.h:222:41: error: attribute 'fallthrough' not preceding a case label or default label [-Werror]
>>    222 | # define fallthrough                    __attribute__((__fallthrough__))
>>        |                                         ^~~~~~~~~~~~~
>> drivers/net/ethernet/intel/ixgbe/ixgbe_xsk.c:147:17: note: in expansion of macro 'fallthrough'
>>    147 |                 fallthrough; /* handle aborts by dropping packet */
>>        |                 ^~~~~~~~~~~
>> cc1: all warnings being treated as errors
>>
>> Caused by commits
>>
>>    b8aef650e549 ("i40e, xsk: Terminate Rx side of NAPI when XSK Rx queue gets full")
>>    c7dd09fd4628 ("ixgbe, xsk: Terminate Rx side of NAPI when XSK Rx queue gets full")
>>
>> I have used the bpf-next tree from next-20220414 for today.
> 
> I am still getting these failures ...
> 

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

[Maciej Fijalkowski]

On Thu, Apr 21, 2022 at 11:45:46AM +0200, Daniel Borkmann wrote:
> On 4/21/22 2:32 AM, Stephen Rothwell wrote:
> > Hi all,
> 
> Maciej, I presume you are already working on a follow-up for the below?

Yikes! I missed that, let's blame easter break for that.
I'm on it.

> 
> > On Tue, 19 Apr 2022 11:56:20 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > > 
> > > After merging the bpf-next tree, today's linux-next build
> > > (x86_64 allmodconfig) failed like this:
> > > 
> > > In file included from include/linux/compiler_types.h:73,
> > >                   from <command-line>:
> > > drivers/net/ethernet/intel/i40e/i40e_xsk.c: In function 'i40e_run_xdp_zc':
> > > include/linux/compiler_attributes.h:222:41: error: attribute 'fallthrough' not preceding a case label or default label [-Werror]
> > >    222 | # define fallthrough                    __attribute__((__fallthrough__))
> > >        |                                         ^~~~~~~~~~~~~
> > > drivers/net/ethernet/intel/i40e/i40e_xsk.c:192:17: note: in expansion of macro 'fallthrough'
> > >    192 |                 fallthrough; /* handle aborts by dropping packet */
> > >        |                 ^~~~~~~~~~~
> > > cc1: all warnings being treated as errors
> > > In file included from include/linux/compiler_types.h:73,
> > >                   from <command-line>:
> > > drivers/net/ethernet/intel/ixgbe/ixgbe_xsk.c: In function 'ixgbe_run_xdp_zc':
> > > include/linux/compiler_attributes.h:222:41: error: attribute 'fallthrough' not preceding a case label or default label [-Werror]
> > >    222 | # define fallthrough                    __attribute__((__fallthrough__))
> > >        |                                         ^~~~~~~~~~~~~
> > > drivers/net/ethernet/intel/ixgbe/ixgbe_xsk.c:147:17: note: in expansion of macro 'fallthrough'
> > >    147 |                 fallthrough; /* handle aborts by dropping packet */
> > >        |                 ^~~~~~~~~~~
> > > cc1: all warnings being treated as errors
> > > 
> > > Caused by commits
> > > 
> > >    b8aef650e549 ("i40e, xsk: Terminate Rx side of NAPI when XSK Rx queue gets full")
> > >    c7dd09fd4628 ("ixgbe, xsk: Terminate Rx side of NAPI when XSK Rx queue gets full")
> > > 
> > > I have used the bpf-next tree from next-20220414 for today.
> > 
> > I am still getting these failures ...
> > 
> 

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

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 922 bytes --]

Hi all,

After merging the bpf-next tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:

ld: warning: discarding dynamic section .glink
ld: warning: discarding dynamic section .plt
ld: linkage table error against `bpf_trampoline_unlink_cgroup_shim'
ld: stubs don't match calculated size
ld: can not build stubs: bad value
ld: kernel/bpf/cgroup.o: in function `.bpf_cgroup_link_release.part.0':
cgroup.c:(.text+0x2fc4): undefined reference to `.bpf_trampoline_unlink_cgroup_shim'
ld: kernel/bpf/cgroup.o: in function `.cgroup_bpf_release':
cgroup.c:(.text+0x33b0): undefined reference to `.bpf_trampoline_unlink_cgroup_shim'
ld: cgroup.c:(.text+0x33c0): undefined reference to `.bpf_trampoline_unlink_cgroup_shim'

Caused by commit

  3908fcddc65d ("bpf: fix lsm_cgroup build errors on esoteric configs")

I have reverted that commit for today.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Alexei Starovoitov]

On Tue, Jul 19, 2022 at 7:00 PM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Hi all,
>
> After merging the bpf-next tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
>
> ld: warning: discarding dynamic section .glink
> ld: warning: discarding dynamic section .plt
> ld: linkage table error against `bpf_trampoline_unlink_cgroup_shim'
> ld: stubs don't match calculated size
> ld: can not build stubs: bad value
> ld: kernel/bpf/cgroup.o: in function `.bpf_cgroup_link_release.part.0':
> cgroup.c:(.text+0x2fc4): undefined reference to `.bpf_trampoline_unlink_cgroup_shim'
> ld: kernel/bpf/cgroup.o: in function `.cgroup_bpf_release':
> cgroup.c:(.text+0x33b0): undefined reference to `.bpf_trampoline_unlink_cgroup_shim'
> ld: cgroup.c:(.text+0x33c0): undefined reference to `.bpf_trampoline_unlink_cgroup_shim'
>
> Caused by commit
>
>   3908fcddc65d ("bpf: fix lsm_cgroup build errors on esoteric configs")
>
> I have reverted that commit for today.

Argh.

Stan,

please take a look.

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

[Stanislav Fomichev]

On Tue, Jul 19, 2022 at 8:42 PM Alexei Starovoitov
<alexei.starovoitov@gmail.com> wrote:
>
> On Tue, Jul 19, 2022 at 7:00 PM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > Hi all,
> >
> > After merging the bpf-next tree, today's linux-next build (powerpc
> > ppc64_defconfig) failed like this:
> >
> > ld: warning: discarding dynamic section .glink
> > ld: warning: discarding dynamic section .plt
> > ld: linkage table error against `bpf_trampoline_unlink_cgroup_shim'
> > ld: stubs don't match calculated size
> > ld: can not build stubs: bad value
> > ld: kernel/bpf/cgroup.o: in function `.bpf_cgroup_link_release.part.0':
> > cgroup.c:(.text+0x2fc4): undefined reference to `.bpf_trampoline_unlink_cgroup_shim'
> > ld: kernel/bpf/cgroup.o: in function `.cgroup_bpf_release':
> > cgroup.c:(.text+0x33b0): undefined reference to `.bpf_trampoline_unlink_cgroup_shim'
> > ld: cgroup.c:(.text+0x33c0): undefined reference to `.bpf_trampoline_unlink_cgroup_shim'
> >
> > Caused by commit
> >
> >   3908fcddc65d ("bpf: fix lsm_cgroup build errors on esoteric configs")
> >
> > I have reverted that commit for today.
>
> Argh.
>
> Stan,
>
> please take a look.

Sorry about that, I forgot to update the ifdef guards in the header
:-( Will send a fix shortly..

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

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 873 bytes --]

Hi all,

After merging the bpf-next tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:

net/bpf/test_run.c: In function 'frame_was_changed':
net/bpf/test_run.c:224:22: error: 'const struct xdp_page_head' has no member named 'frm'; did you mean 'frame'?
  224 |         return head->frm.data != head->orig_ctx.data ||
      |                      ^~~
      |                      frame
net/bpf/test_run.c:225:22: error: 'const struct xdp_page_head' has no member named 'frm'; did you mean 'frame'?
  225 |                head->frm.flags != head->orig_ctx.flags;
      |                      ^~~
      |                      frame

Caused by commit

  e5995bc7e2ba ("bpf, test_run: fix crashes due to XDP frame overwriting/corruption")

I have used the bpf-next tree from next-20230317 for today.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Alexander Lobakin]

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Mon, 20 Mar 2023 10:26:19 +1100

> Hi all,

Hi,

> 
> After merging the bpf-next tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
> 
> net/bpf/test_run.c: In function 'frame_was_changed':
> net/bpf/test_run.c:224:22: error: 'const struct xdp_page_head' has no member named 'frm'; did you mean 'frame'?
>   224 |         return head->frm.data != head->orig_ctx.data ||
>       |                      ^~~
>       |                      frame
> net/bpf/test_run.c:225:22: error: 'const struct xdp_page_head' has no member named 'frm'; did you mean 'frame'?
>   225 |                head->frm.flags != head->orig_ctx.flags;
>       |                      ^~~
>       |                      frame

The correct solution is to change `frm.` with `frame->`, but I hope the
BPF maintainers will merge bpf into bpf-next to pick up fixes and
changes like this :)

> 
> Caused by commit
> 
>   e5995bc7e2ba ("bpf, test_run: fix crashes due to XDP frame overwriting/corruption")
> 
> I have used the bpf-next tree from next-20230317 for today.
> 

Thanks,
Olek

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

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 2222 bytes --]

Hi all,

On Mon, 20 Mar 2023 13:07:23 +0100 Alexander Lobakin <aleksander.lobakin@intel.com> wrote:
>
> > After merging the bpf-next tree, today's linux-next build (powerpc
> > ppc64_defconfig) failed like this:
> > 
> > net/bpf/test_run.c: In function 'frame_was_changed':
> > net/bpf/test_run.c:224:22: error: 'const struct xdp_page_head' has no member named 'frm'; did you mean 'frame'?
> >   224 |         return head->frm.data != head->orig_ctx.data ||
> >       |                      ^~~
> >       |                      frame
> > net/bpf/test_run.c:225:22: error: 'const struct xdp_page_head' has no member named 'frm'; did you mean 'frame'?
> >   225 |                head->frm.flags != head->orig_ctx.flags;
> >       |                      ^~~
> >       |                      frame  
> 
> The correct solution is to change `frm.` with `frame->`, but I hope the
> BPF maintainers will merge bpf into bpf-next to pick up fixes and
> changes like this :)

Well, that hasn't happened yet, so I will apply the following patch
until it does.

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Wed, 22 Mar 2023 09:20:26 +1100
Subject: [PATCH] bpf, test_run: fix up for "bpf, test_run: fix &xdp_frame misplacement for LIVE_FRAMES"

ineracting with commit

  e5995bc7e2ba ("bpf, test_run: fix crashes due to XDP frame overwriting/corruption")

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 net/bpf/test_run.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/net/bpf/test_run.c b/net/bpf/test_run.c
index af5804d6bff2..c2bab8e20406 100644
--- a/net/bpf/test_run.c
+++ b/net/bpf/test_run.c
@@ -221,8 +221,8 @@ static bool frame_was_changed(const struct xdp_page_head *head)
 	 * i.e. has the highest chances to be overwritten. If those two are
 	 * untouched, it's most likely safe to skip the context reset.
 	 */
-	return head->frm.data != head->orig_ctx.data ||
-	       head->frm.flags != head->orig_ctx.flags;
+	return head->frame->data != head->orig_ctx.data ||
+	       head->frame->flags != head->orig_ctx.flags;
 }
 
 static bool ctx_was_changed(struct xdp_page_head *head)
-- 
2.39.2

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 2398 bytes --]

Hi all,

After merging the bpf-next tree, today's linux-next build (x86_64
allmodconfig) failed like this:

/tmp/next/build/drivers/hid/bpf/hid_bpf_struct_ops.c:280:16: error: initialization of 'int (*)(void *, struct bpf_link *)' from incompatible pointer type 'int (*)(void *)' [-Werror=incompatible-pointer-types]
  280 |         .reg = hid_bpf_reg,
      |                ^~~~~~~~~~~
/tmp/next/build/drivers/hid/bpf/hid_bpf_struct_ops.c:280:16: note: (near initialization for 'bpf_hid_bpf_ops.reg')
/tmp/next/build/drivers/hid/bpf/hid_bpf_struct_ops.c:281:18: error: initialization of 'void (*)(void *, struct bpf_link *)' from incompatible pointer type 'void (*)(void *)' [-Werror=incompatible-pointer-types]
  281 |         .unreg = hid_bpf_unreg,
      |                  ^~~~~~~~~~~~~
/tmp/next/build/drivers/hid/bpf/hid_bpf_struct_ops.c:281:18: note: (near initialization for 'bpf_hid_bpf_ops.unreg')

Caused by commit

  73287fe228721b ("bpf: pass bpf_struct_ops_link to callbacks in bpf_struct_ops.")

interacting with commit

  ebc0d8093e8c97 ("HID: bpf: implement HID-BPF through bpf_struct_ops")

from the HID tree.

I've fixed it up as below:

From e8aeaba00440845f9bd8d6183ca5d7383a678cd3 Mon Sep 17 00:00:00 2001
From: Mark Brown <broonie@kernel.org>
Date: Mon, 17 Jun 2024 19:02:27 +0100
Subject: [PATCH] HID: bpf: Fix up build

Fix up build error due to 73287fe228721b ("bpf: pass bpf_struct_ops_link to callbacks in bpf_struct_ops.")

Signed-off-by: Mark Brown <broonie@kernel.org>
---
 drivers/hid/bpf/hid_bpf_struct_ops.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/hid/bpf/hid_bpf_struct_ops.c b/drivers/hid/bpf/hid_bpf_struct_ops.c
index 5f200557ff12b..744318e7d936b 100644
--- a/drivers/hid/bpf/hid_bpf_struct_ops.c
+++ b/drivers/hid/bpf/hid_bpf_struct_ops.c
@@ -175,7 +175,7 @@ static int hid_bpf_ops_init_member(const struct btf_type *t,
 	return 0;
 }
 
-static int hid_bpf_reg(void *kdata)
+static int hid_bpf_reg(void *kdata, struct bpf_link *link)
 {
 	struct hid_bpf_ops *ops = kdata;
 	struct hid_device *hdev;
@@ -229,7 +229,7 @@ static int hid_bpf_reg(void *kdata)
 	return err;
 }
 
-static void hid_bpf_unreg(void *kdata)
+static void hid_bpf_unreg(void *kdata, struct bpf_link *link)
 {
 	struct hid_bpf_ops *ops = kdata;
 	struct hid_device *hdev;
-- 
2.39.2


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[kernel test robot]

Hi Mark,

kernel test robot noticed the following build errors:

[auto build test ERROR on hid/for-next]
[cannot apply to linus/master v6.10-rc4 next-20240621]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]

url:    https://github.com/intel-lab-lkp/linux/commits/Mark-Brown/linux-next-build-failure-after-merge-of-the-bpf-next-tree/20240618-022240
base:   https://git.kernel.org/pub/scm/linux/kernel/git/hid/hid.git for-next
patch link:    https://lore.kernel.org/r/ZnB9X1Jj6c04ufC0%40sirena.org.uk
patch subject: linux-next: build failure after merge of the bpf-next tree
config: x86_64-randconfig-r122-20240622 (https://download.01.org/0day-ci/archive/20240622/202406221655.xSqDIUk6-lkp@intel.com/config)
compiler: clang version 18.1.5 (https://github.com/llvm/llvm-project 617a15a9eac96088ae5e9134248d8236e34b91b1)
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20240622/202406221655.xSqDIUk6-lkp@intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202406221655.xSqDIUk6-lkp@intel.com/

All errors (new ones prefixed by >>):

>> drivers/hid/bpf/hid_bpf_struct_ops.c:280:9: error: incompatible function pointer types initializing 'int (*)(void *)' with an expression of type 'int (void *, struct bpf_link *)' [-Wincompatible-function-pointer-types]
     280 |         .reg = hid_bpf_reg,
         |                ^~~~~~~~~~~
>> drivers/hid/bpf/hid_bpf_struct_ops.c:281:11: error: incompatible function pointer types initializing 'void (*)(void *)' with an expression of type 'void (void *, struct bpf_link *)' [-Wincompatible-function-pointer-types]
     281 |         .unreg = hid_bpf_unreg,
         |                  ^~~~~~~~~~~~~
   2 errors generated.


vim +280 drivers/hid/bpf/hid_bpf_struct_ops.c

ebc0d8093e8c97 Benjamin Tissoires 2024-06-08  274  
ebc0d8093e8c97 Benjamin Tissoires 2024-06-08  275  static struct bpf_struct_ops bpf_hid_bpf_ops = {
ebc0d8093e8c97 Benjamin Tissoires 2024-06-08  276  	.verifier_ops = &hid_bpf_verifier_ops,
ebc0d8093e8c97 Benjamin Tissoires 2024-06-08  277  	.init = hid_bpf_ops_init,
ebc0d8093e8c97 Benjamin Tissoires 2024-06-08  278  	.check_member = hid_bpf_ops_check_member,
ebc0d8093e8c97 Benjamin Tissoires 2024-06-08  279  	.init_member = hid_bpf_ops_init_member,
ebc0d8093e8c97 Benjamin Tissoires 2024-06-08 @280  	.reg = hid_bpf_reg,
ebc0d8093e8c97 Benjamin Tissoires 2024-06-08 @281  	.unreg = hid_bpf_unreg,
ebc0d8093e8c97 Benjamin Tissoires 2024-06-08  282  	.name = "hid_bpf_ops",
ebc0d8093e8c97 Benjamin Tissoires 2024-06-08  283  	.cfi_stubs = &__bpf_hid_bpf_ops,
ebc0d8093e8c97 Benjamin Tissoires 2024-06-08  284  	.owner = THIS_MODULE,
ebc0d8093e8c97 Benjamin Tissoires 2024-06-08  285  };
ebc0d8093e8c97 Benjamin Tissoires 2024-06-08  286  

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki

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

[kernel test robot]

Hi Mark,

kernel test robot noticed the following build errors:

[auto build test ERROR on hid/for-next]
[cannot apply to linus/master v6.10-rc4 next-20240621]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]

url:    https://github.com/intel-lab-lkp/linux/commits/Mark-Brown/linux-next-build-failure-after-merge-of-the-bpf-next-tree/20240618-022240
base:   https://git.kernel.org/pub/scm/linux/kernel/git/hid/hid.git for-next
patch link:    https://lore.kernel.org/r/ZnB9X1Jj6c04ufC0%40sirena.org.uk
patch subject: linux-next: build failure after merge of the bpf-next tree
config: i386-allmodconfig (https://download.01.org/0day-ci/archive/20240622/202406221626.JK0Nnkxy-lkp@intel.com/config)
compiler: gcc-13 (Ubuntu 13.2.0-4ubuntu3) 13.2.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20240622/202406221626.JK0Nnkxy-lkp@intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202406221626.JK0Nnkxy-lkp@intel.com/

All errors (new ones prefixed by >>):

>> drivers/hid/bpf/hid_bpf_struct_ops.c:280:16: error: initialization of 'int (*)(void *)' from incompatible pointer type 'int (*)(void *, struct bpf_link *)' [-Werror=incompatible-pointer-types]
     280 |         .reg = hid_bpf_reg,
         |                ^~~~~~~~~~~
   drivers/hid/bpf/hid_bpf_struct_ops.c:280:16: note: (near initialization for 'bpf_hid_bpf_ops.reg')
>> drivers/hid/bpf/hid_bpf_struct_ops.c:281:18: error: initialization of 'void (*)(void *)' from incompatible pointer type 'void (*)(void *, struct bpf_link *)' [-Werror=incompatible-pointer-types]
     281 |         .unreg = hid_bpf_unreg,
         |                  ^~~~~~~~~~~~~
   drivers/hid/bpf/hid_bpf_struct_ops.c:281:18: note: (near initialization for 'bpf_hid_bpf_ops.unreg')
   cc1: some warnings being treated as errors


vim +280 drivers/hid/bpf/hid_bpf_struct_ops.c

ebc0d8093e8c97 Benjamin Tissoires 2024-06-08  274  
ebc0d8093e8c97 Benjamin Tissoires 2024-06-08  275  static struct bpf_struct_ops bpf_hid_bpf_ops = {
ebc0d8093e8c97 Benjamin Tissoires 2024-06-08  276  	.verifier_ops = &hid_bpf_verifier_ops,
ebc0d8093e8c97 Benjamin Tissoires 2024-06-08  277  	.init = hid_bpf_ops_init,
ebc0d8093e8c97 Benjamin Tissoires 2024-06-08  278  	.check_member = hid_bpf_ops_check_member,
ebc0d8093e8c97 Benjamin Tissoires 2024-06-08  279  	.init_member = hid_bpf_ops_init_member,
ebc0d8093e8c97 Benjamin Tissoires 2024-06-08 @280  	.reg = hid_bpf_reg,
ebc0d8093e8c97 Benjamin Tissoires 2024-06-08 @281  	.unreg = hid_bpf_unreg,
ebc0d8093e8c97 Benjamin Tissoires 2024-06-08  282  	.name = "hid_bpf_ops",
ebc0d8093e8c97 Benjamin Tissoires 2024-06-08  283  	.cfi_stubs = &__bpf_hid_bpf_ops,
ebc0d8093e8c97 Benjamin Tissoires 2024-06-08  284  	.owner = THIS_MODULE,
ebc0d8093e8c97 Benjamin Tissoires 2024-06-08  285  };
ebc0d8093e8c97 Benjamin Tissoires 2024-06-08  286  

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki

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

[Thinker Li]

Hi Mark,

I'm sorry for not getting back to you sooner. I have been traveling
since my last message.
I guess this patch is for the HID tree. The changes in this patch are great.

However, I suggest you implement ".update" if you think it is
reasonable for HID,
although it is not a MUST-BE. ".update" provides a good feature that
user space programs
can update an implementation on the flight.

On Mon, Jun 17, 2024 at 11:16 AM Mark Brown <broonie@kernel.org> wrote:
>
> Hi all,
>
> After merging the bpf-next tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> /tmp/next/build/drivers/hid/bpf/hid_bpf_struct_ops.c:280:16: error: initialization of 'int (*)(void *, struct bpf_link *)' from incompatible pointer type 'int (*)(void *)' [-Werror=incompatible-pointer-types]
>   280 |         .reg = hid_bpf_reg,
>       |                ^~~~~~~~~~~
> /tmp/next/build/drivers/hid/bpf/hid_bpf_struct_ops.c:280:16: note: (near initialization for 'bpf_hid_bpf_ops.reg')
> /tmp/next/build/drivers/hid/bpf/hid_bpf_struct_ops.c:281:18: error: initialization of 'void (*)(void *, struct bpf_link *)' from incompatible pointer type 'void (*)(void *)' [-Werror=incompatible-pointer-types]
>   281 |         .unreg = hid_bpf_unreg,
>       |                  ^~~~~~~~~~~~~
> /tmp/next/build/drivers/hid/bpf/hid_bpf_struct_ops.c:281:18: note: (near initialization for 'bpf_hid_bpf_ops.unreg')
>
> Caused by commit
>
>   73287fe228721b ("bpf: pass bpf_struct_ops_link to callbacks in bpf_struct_ops.")
>
> interacting with commit
>
>   ebc0d8093e8c97 ("HID: bpf: implement HID-BPF through bpf_struct_ops")
>
> from the HID tree.
>
> I've fixed it up as below:
>
> From e8aeaba00440845f9bd8d6183ca5d7383a678cd3 Mon Sep 17 00:00:00 2001
> From: Mark Brown <broonie@kernel.org>
> Date: Mon, 17 Jun 2024 19:02:27 +0100
> Subject: [PATCH] HID: bpf: Fix up build
>
> Fix up build error due to 73287fe228721b ("bpf: pass bpf_struct_ops_link to callbacks in bpf_struct_ops.")
>
> Signed-off-by: Mark Brown <broonie@kernel.org>
> ---
>  drivers/hid/bpf/hid_bpf_struct_ops.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/hid/bpf/hid_bpf_struct_ops.c b/drivers/hid/bpf/hid_bpf_struct_ops.c
> index 5f200557ff12b..744318e7d936b 100644
> --- a/drivers/hid/bpf/hid_bpf_struct_ops.c
> +++ b/drivers/hid/bpf/hid_bpf_struct_ops.c
> @@ -175,7 +175,7 @@ static int hid_bpf_ops_init_member(const struct btf_type *t,
>         return 0;
>  }
>
> -static int hid_bpf_reg(void *kdata)
> +static int hid_bpf_reg(void *kdata, struct bpf_link *link)
>  {
>         struct hid_bpf_ops *ops = kdata;
>         struct hid_device *hdev;
> @@ -229,7 +229,7 @@ static int hid_bpf_reg(void *kdata)
>         return err;
>  }
>
> -static void hid_bpf_unreg(void *kdata)
> +static void hid_bpf_unreg(void *kdata, struct bpf_link *link)
>  {
>         struct hid_bpf_ops *ops = kdata;
>         struct hid_device *hdev;
> --
> 2.39.2
>

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

[Benjamin Tissoires]

On Jun 24 2024, Thinker Li wrote:
> Hi Mark,
> 
> I'm sorry for not getting back to you sooner. I have been traveling
> since my last message.
> I guess this patch is for the HID tree. The changes in this patch are great.

Ok, thanks for the review. However, the need appears because there is a
conflicting update in the bpf tree.

May I ask the bpf maintainers (Daniel/Alexei/Andrii) for an immutable
tag I could merge to so I can take this patch from Mark?

> 
> However, I suggest you implement ".update" if you think it is
> reasonable for HID,
> although it is not a MUST-BE. ".update" provides a good feature that
> user space programs
> can update an implementation on the flight.

FWIW, Mark handles linux-next, so not sure he has deep knowledge of
HID-BPF, and not sure he wants too :)

Regarding .update, I'm not sure it's worth the effort for hid-bpf. Right
now HID-BPF programs are just a one-shot: you load them, pin them and
forget. This might be different when systemd starts implementing a HID
firewall, but we can cross that bridge when we see fit.

Cheers,
Benjamin

> 
> On Mon, Jun 17, 2024 at 11:16 AM Mark Brown <broonie@kernel.org> wrote:
> >
> > Hi all,
> >
> > After merging the bpf-next tree, today's linux-next build (x86_64
> > allmodconfig) failed like this:
> >
> > /tmp/next/build/drivers/hid/bpf/hid_bpf_struct_ops.c:280:16: error: initialization of 'int (*)(void *, struct bpf_link *)' from incompatible pointer type 'int (*)(void *)' [-Werror=incompatible-pointer-types]
> >   280 |         .reg = hid_bpf_reg,
> >       |                ^~~~~~~~~~~
> > /tmp/next/build/drivers/hid/bpf/hid_bpf_struct_ops.c:280:16: note: (near initialization for 'bpf_hid_bpf_ops.reg')
> > /tmp/next/build/drivers/hid/bpf/hid_bpf_struct_ops.c:281:18: error: initialization of 'void (*)(void *, struct bpf_link *)' from incompatible pointer type 'void (*)(void *)' [-Werror=incompatible-pointer-types]
> >   281 |         .unreg = hid_bpf_unreg,
> >       |                  ^~~~~~~~~~~~~
> > /tmp/next/build/drivers/hid/bpf/hid_bpf_struct_ops.c:281:18: note: (near initialization for 'bpf_hid_bpf_ops.unreg')
> >
> > Caused by commit
> >
> >   73287fe228721b ("bpf: pass bpf_struct_ops_link to callbacks in bpf_struct_ops.")
> >
> > interacting with commit
> >
> >   ebc0d8093e8c97 ("HID: bpf: implement HID-BPF through bpf_struct_ops")
> >
> > from the HID tree.
> >
> > I've fixed it up as below:
> >
> > From e8aeaba00440845f9bd8d6183ca5d7383a678cd3 Mon Sep 17 00:00:00 2001
> > From: Mark Brown <broonie@kernel.org>
> > Date: Mon, 17 Jun 2024 19:02:27 +0100
> > Subject: [PATCH] HID: bpf: Fix up build
> >
> > Fix up build error due to 73287fe228721b ("bpf: pass bpf_struct_ops_link to callbacks in bpf_struct_ops.")
> >
> > Signed-off-by: Mark Brown <broonie@kernel.org>
> > ---
> >  drivers/hid/bpf/hid_bpf_struct_ops.c | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/hid/bpf/hid_bpf_struct_ops.c b/drivers/hid/bpf/hid_bpf_struct_ops.c
> > index 5f200557ff12b..744318e7d936b 100644
> > --- a/drivers/hid/bpf/hid_bpf_struct_ops.c
> > +++ b/drivers/hid/bpf/hid_bpf_struct_ops.c
> > @@ -175,7 +175,7 @@ static int hid_bpf_ops_init_member(const struct btf_type *t,
> >         return 0;
> >  }
> >
> > -static int hid_bpf_reg(void *kdata)
> > +static int hid_bpf_reg(void *kdata, struct bpf_link *link)
> >  {
> >         struct hid_bpf_ops *ops = kdata;
> >         struct hid_device *hdev;
> > @@ -229,7 +229,7 @@ static int hid_bpf_reg(void *kdata)
> >         return err;
> >  }
> >
> > -static void hid_bpf_unreg(void *kdata)
> > +static void hid_bpf_unreg(void *kdata, struct bpf_link *link)
> >  {
> >         struct hid_bpf_ops *ops = kdata;
> >         struct hid_device *hdev;
> > --
> > 2.39.2
> >

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

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 480 bytes --]

On Tue, Jun 25, 2024 at 05:54:47PM +0200, Benjamin Tissoires wrote:
> On Jun 24 2024, Thinker Li wrote:

> > However, I suggest you implement ".update" if you think it is
> > reasonable for HID,
> > although it is not a MUST-BE. ".update" provides a good feature that
> > user space programs
> > can update an implementation on the flight.

> FWIW, Mark handles linux-next, so not sure he has deep knowledge of
> HID-BPF, and not sure he wants too :)

Only holiday cover but yes.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Alexei Starovoitov]

On Tue, Jun 25, 2024 at 8:54 AM Benjamin Tissoires <bentiss@kernel.org> wrote:
>
> On Jun 24 2024, Thinker Li wrote:
> > Hi Mark,
> >
> > I'm sorry for not getting back to you sooner. I have been traveling
> > since my last message.
> > I guess this patch is for the HID tree. The changes in this patch are great.
>
> Ok, thanks for the review. However, the need appears because there is a
> conflicting update in the bpf tree.
>
> May I ask the bpf maintainers (Daniel/Alexei/Andrii) for an immutable
> tag I could merge to so I can take this patch from Mark?

I'm not sure how that would look like.
imo conflict is minor enough.
When net-next/bpf-next lands in the upcoming merge window
just provide Mark's patch as a conflict resolution suggestion
in the cover letter of hid PR ?

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

[Benjamin Tissoires]

On Jun 25 2024, Alexei Starovoitov wrote:
> On Tue, Jun 25, 2024 at 8:54 AM Benjamin Tissoires <bentiss@kernel.org> wrote:
> >
> > On Jun 24 2024, Thinker Li wrote:
> > > Hi Mark,
> > >
> > > I'm sorry for not getting back to you sooner. I have been traveling
> > > since my last message.
> > > I guess this patch is for the HID tree. The changes in this patch are great.
> >
> > Ok, thanks for the review. However, the need appears because there is a
> > conflicting update in the bpf tree.
> >
> > May I ask the bpf maintainers (Daniel/Alexei/Andrii) for an immutable
> > tag I could merge to so I can take this patch from Mark?
> 
> I'm not sure how that would look like.
> imo conflict is minor enough.
> When net-next/bpf-next lands in the upcoming merge window
> just provide Mark's patch as a conflict resolution suggestion
> in the cover letter of hid PR ?

I guess I can also wait for the bpf PR to come in, merge with it and add
Mark's patch at that time. It's not so much of a conflict but 2
independant changes in 2 different trees.

Anyway, we'll figure it out when we need :)

Cheers,
Benjamin

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

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 2707 bytes --]

Hi all,

On Mon, 17 Jun 2024 19:15:59 +0100 Mark Brown <broonie@kernel.org> wrote:
>
> After merging the bpf-next tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
> 
> /tmp/next/build/drivers/hid/bpf/hid_bpf_struct_ops.c:280:16: error: initialization of 'int (*)(void *, struct bpf_link *)' from incompatible pointer type 'int (*)(void *)' [-Werror=incompatible-pointer-types]
>   280 |         .reg = hid_bpf_reg,
>       |                ^~~~~~~~~~~
> /tmp/next/build/drivers/hid/bpf/hid_bpf_struct_ops.c:280:16: note: (near initialization for 'bpf_hid_bpf_ops.reg')
> /tmp/next/build/drivers/hid/bpf/hid_bpf_struct_ops.c:281:18: error: initialization of 'void (*)(void *, struct bpf_link *)' from incompatible pointer type 'void (*)(void *)' [-Werror=incompatible-pointer-types]
>   281 |         .unreg = hid_bpf_unreg,
>       |                  ^~~~~~~~~~~~~
> /tmp/next/build/drivers/hid/bpf/hid_bpf_struct_ops.c:281:18: note: (near initialization for 'bpf_hid_bpf_ops.unreg')
> 
> Caused by commit
> 
>   73287fe228721b ("bpf: pass bpf_struct_ops_link to callbacks in bpf_struct_ops.")
> 
> interacting with commit
> 
>   ebc0d8093e8c97 ("HID: bpf: implement HID-BPF through bpf_struct_ops")
> 
> from the HID tree.
> 
> I've fixed it up as below:
> 
> From e8aeaba00440845f9bd8d6183ca5d7383a678cd3 Mon Sep 17 00:00:00 2001
> From: Mark Brown <broonie@kernel.org>
> Date: Mon, 17 Jun 2024 19:02:27 +0100
> Subject: [PATCH] HID: bpf: Fix up build
> 
> Fix up build error due to 73287fe228721b ("bpf: pass bpf_struct_ops_link to callbacks in bpf_struct_ops.")
> 
> Signed-off-by: Mark Brown <broonie@kernel.org>
> ---
>  drivers/hid/bpf/hid_bpf_struct_ops.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/hid/bpf/hid_bpf_struct_ops.c b/drivers/hid/bpf/hid_bpf_struct_ops.c
> index 5f200557ff12b..744318e7d936b 100644
> --- a/drivers/hid/bpf/hid_bpf_struct_ops.c
> +++ b/drivers/hid/bpf/hid_bpf_struct_ops.c
> @@ -175,7 +175,7 @@ static int hid_bpf_ops_init_member(const struct btf_type *t,
>  	return 0;
>  }
>  
> -static int hid_bpf_reg(void *kdata)
> +static int hid_bpf_reg(void *kdata, struct bpf_link *link)
>  {
>  	struct hid_bpf_ops *ops = kdata;
>  	struct hid_device *hdev;
> @@ -229,7 +229,7 @@ static int hid_bpf_reg(void *kdata)
>  	return err;
>  }
>  
> -static void hid_bpf_unreg(void *kdata)
> +static void hid_bpf_unreg(void *kdata, struct bpf_link *link)
>  {
>  	struct hid_bpf_ops *ops = kdata;
>  	struct hid_device *hdev;
> -- 
> 2.39.2
> 

This fixup is now required when the hid and next-next trees are merged.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 2997 bytes --]

Hi all,

On Wed, 10 Jul 2024 09:13:44 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> On Mon, 17 Jun 2024 19:15:59 +0100 Mark Brown <broonie@kernel.org> wrote:
> >
> > After merging the bpf-next tree, today's linux-next build (x86_64
> > allmodconfig) failed like this:
> > 
> > /tmp/next/build/drivers/hid/bpf/hid_bpf_struct_ops.c:280:16: error: initialization of 'int (*)(void *, struct bpf_link *)' from incompatible pointer type 'int (*)(void *)' [-Werror=incompatible-pointer-types]
> >   280 |         .reg = hid_bpf_reg,
> >       |                ^~~~~~~~~~~
> > /tmp/next/build/drivers/hid/bpf/hid_bpf_struct_ops.c:280:16: note: (near initialization for 'bpf_hid_bpf_ops.reg')
> > /tmp/next/build/drivers/hid/bpf/hid_bpf_struct_ops.c:281:18: error: initialization of 'void (*)(void *, struct bpf_link *)' from incompatible pointer type 'void (*)(void *)' [-Werror=incompatible-pointer-types]
> >   281 |         .unreg = hid_bpf_unreg,
> >       |                  ^~~~~~~~~~~~~
> > /tmp/next/build/drivers/hid/bpf/hid_bpf_struct_ops.c:281:18: note: (near initialization for 'bpf_hid_bpf_ops.unreg')
> > 
> > Caused by commit
> > 
> >   73287fe228721b ("bpf: pass bpf_struct_ops_link to callbacks in bpf_struct_ops.")
> > 
> > interacting with commit
> > 
> >   ebc0d8093e8c97 ("HID: bpf: implement HID-BPF through bpf_struct_ops")
> > 
> > from the HID tree.
> > 
> > I've fixed it up as below:
> > 
> > From e8aeaba00440845f9bd8d6183ca5d7383a678cd3 Mon Sep 17 00:00:00 2001
> > From: Mark Brown <broonie@kernel.org>
> > Date: Mon, 17 Jun 2024 19:02:27 +0100
> > Subject: [PATCH] HID: bpf: Fix up build
> > 
> > Fix up build error due to 73287fe228721b ("bpf: pass bpf_struct_ops_link to callbacks in bpf_struct_ops.")
> > 
> > Signed-off-by: Mark Brown <broonie@kernel.org>
> > ---
> >  drivers/hid/bpf/hid_bpf_struct_ops.c | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/hid/bpf/hid_bpf_struct_ops.c b/drivers/hid/bpf/hid_bpf_struct_ops.c
> > index 5f200557ff12b..744318e7d936b 100644
> > --- a/drivers/hid/bpf/hid_bpf_struct_ops.c
> > +++ b/drivers/hid/bpf/hid_bpf_struct_ops.c
> > @@ -175,7 +175,7 @@ static int hid_bpf_ops_init_member(const struct btf_type *t,
> >  	return 0;
> >  }
> >  
> > -static int hid_bpf_reg(void *kdata)
> > +static int hid_bpf_reg(void *kdata, struct bpf_link *link)
> >  {
> >  	struct hid_bpf_ops *ops = kdata;
> >  	struct hid_device *hdev;
> > @@ -229,7 +229,7 @@ static int hid_bpf_reg(void *kdata)
> >  	return err;
> >  }
> >  
> > -static void hid_bpf_unreg(void *kdata)
> > +static void hid_bpf_unreg(void *kdata, struct bpf_link *link)
> >  {
> >  	struct hid_bpf_ops *ops = kdata;
> >  	struct hid_device *hdev;
> > -- 
> > 2.39.2
> >   
> 
> This fixup is now required when the hid and next-next trees are merged.

And now this is needed when the hid tree is merged with Linus' tree.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Benjamin Tissoires]

Hi Stephen,

On Jul 18 2024, Stephen Rothwell wrote:
> Hi all,
> 
> On Wed, 10 Jul 2024 09:13:44 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > On Mon, 17 Jun 2024 19:15:59 +0100 Mark Brown <broonie@kernel.org> wrote:
> > >
> > > After merging the bpf-next tree, today's linux-next build (x86_64
> > > allmodconfig) failed like this:
> > > 
> > > /tmp/next/build/drivers/hid/bpf/hid_bpf_struct_ops.c:280:16: error: initialization of 'int (*)(void *, struct bpf_link *)' from incompatible pointer type 'int (*)(void *)' [-Werror=incompatible-pointer-types]
> > >   280 |         .reg = hid_bpf_reg,
> > >       |                ^~~~~~~~~~~
> > > /tmp/next/build/drivers/hid/bpf/hid_bpf_struct_ops.c:280:16: note: (near initialization for 'bpf_hid_bpf_ops.reg')
> > > /tmp/next/build/drivers/hid/bpf/hid_bpf_struct_ops.c:281:18: error: initialization of 'void (*)(void *, struct bpf_link *)' from incompatible pointer type 'void (*)(void *)' [-Werror=incompatible-pointer-types]
> > >   281 |         .unreg = hid_bpf_unreg,
> > >       |                  ^~~~~~~~~~~~~
> > > /tmp/next/build/drivers/hid/bpf/hid_bpf_struct_ops.c:281:18: note: (near initialization for 'bpf_hid_bpf_ops.unreg')
> > > 
> > > Caused by commit
> > > 
> > >   73287fe228721b ("bpf: pass bpf_struct_ops_link to callbacks in bpf_struct_ops.")
> > > 
> > > interacting with commit
> > > 
> > >   ebc0d8093e8c97 ("HID: bpf: implement HID-BPF through bpf_struct_ops")
> > > 
> > > from the HID tree.
> > > 
> > > I've fixed it up as below:
> > > 
> > > From e8aeaba00440845f9bd8d6183ca5d7383a678cd3 Mon Sep 17 00:00:00 2001
> > > From: Mark Brown <broonie@kernel.org>
> > > Date: Mon, 17 Jun 2024 19:02:27 +0100
> > > Subject: [PATCH] HID: bpf: Fix up build
> > > 
> > > Fix up build error due to 73287fe228721b ("bpf: pass bpf_struct_ops_link to callbacks in bpf_struct_ops.")
> > > 
> > > Signed-off-by: Mark Brown <broonie@kernel.org>
> > > ---
> > >  drivers/hid/bpf/hid_bpf_struct_ops.c | 4 ++--
> > >  1 file changed, 2 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/drivers/hid/bpf/hid_bpf_struct_ops.c b/drivers/hid/bpf/hid_bpf_struct_ops.c
> > > index 5f200557ff12b..744318e7d936b 100644
> > > --- a/drivers/hid/bpf/hid_bpf_struct_ops.c
> > > +++ b/drivers/hid/bpf/hid_bpf_struct_ops.c
> > > @@ -175,7 +175,7 @@ static int hid_bpf_ops_init_member(const struct btf_type *t,
> > >  	return 0;
> > >  }
> > >  
> > > -static int hid_bpf_reg(void *kdata)
> > > +static int hid_bpf_reg(void *kdata, struct bpf_link *link)
> > >  {
> > >  	struct hid_bpf_ops *ops = kdata;
> > >  	struct hid_device *hdev;
> > > @@ -229,7 +229,7 @@ static int hid_bpf_reg(void *kdata)
> > >  	return err;
> > >  }
> > >  
> > > -static void hid_bpf_unreg(void *kdata)
> > > +static void hid_bpf_unreg(void *kdata, struct bpf_link *link)
> > >  {
> > >  	struct hid_bpf_ops *ops = kdata;
> > >  	struct hid_device *hdev;
> > > -- 
> > > 2.39.2
> > >   
> > 
> > This fixup is now required when the hid and next-next trees are merged.
> 
> And now this is needed when the hid tree is merged with Linus' tree.
> 

Thanks a lot for all of your reminders.

The HID PR has been accepted and merged thanks to both of your merge
conflicts detection, Mark and you. So this conflict should no longer be a
problem.

Cheers,
Benjamin

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

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 2292 bytes --]

Hi all,

After merging the bpf-next tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:

fs/namespace.c: In function 'grab_requested_mnt_ns':
fs/namespace.c:5295:23: error: 'class_fd_t' {aka 'struct fd'} has no member named 'file'
 5295 |                 if (!f.file)
      |                       ^
fs/namespace.c:5298:36: error: 'class_fd_t' {aka 'struct fd'} has no member named 'file'
 5298 |                 if (!proc_ns_file(f.file))
      |                                    ^
In file included from fs/namespace.c:25:
fs/namespace.c:5301:46: error: 'class_fd_t' {aka 'struct fd'} has no member named 'file'
 5301 |                 ns = get_proc_ns(file_inode(f.file));
      |                                              ^
include/linux/proc_ns.h:75:50: note: in definition of macro 'get_proc_ns'
   75 | #define get_proc_ns(inode) ((struct ns_common *)(inode)->i_private)
      |                                                  ^~~~~

Caused by commit

  1da91ea87aef ("introduce fd_file(), convert all accessors to it.")

interacting with commit

  7b9d14af8777 ("fs: allow mount namespace fd")

from the vfs-brauner tree.

I applied the following merge fix patch:

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Wed, 14 Aug 2024 11:07:38 +1000
Subject: [PATCH] fixup for "introduce fd_file(), convert all accessors to it."

interacting with "fs: allow mount namespace fd" from hte vfs-brauner tree.

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 fs/namespace.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/fs/namespace.c b/fs/namespace.c
index 159be8ed9d24..7aed325c48ad 100644
--- a/fs/namespace.c
+++ b/fs/namespace.c
@@ -5292,13 +5292,13 @@ static struct mnt_namespace *grab_requested_mnt_ns(const struct mnt_id_req *kreq
 		struct ns_common *ns;
 
 		CLASS(fd, f)(kreq->spare);
-		if (!f.file)
+		if (!fd_file(f))
 			return ERR_PTR(-EBADF);
 
-		if (!proc_ns_file(f.file))
+		if (!proc_ns_file(fd_file(f)))
 			return ERR_PTR(-EINVAL);
 
-		ns = get_proc_ns(file_inode(f.file));
+		ns = get_proc_ns(file_inode(fd_file(f)));
 		if (ns->ops->type != CLONE_NEWNS)
 			return ERR_PTR(-EINVAL);
 
-- 
2.43.0

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 5791 bytes --]

Hi all,

After merging the bpf-next tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:

fs/xattr.c: In function 'path_getxattrat':
fs/xattr.c:832:23: error: 'class_fd_t' {aka 'struct fd'} has no member named 'file'
  832 |                 if (!f.file)
      |                       ^
fs/xattr.c:834:29: error: 'class_fd_t' {aka 'struct fd'} has no member named 'file'
  834 |                 audit_file(f.file);
      |                             ^
fs/xattr.c:835:49: error: 'class_fd_t' {aka 'struct fd'} has no member named 'file'
  835 |                 return getxattr(file_mnt_idmap(f.file), file_dentry(f.file),
      |                                                 ^
fs/xattr.c:835:70: error: 'class_fd_t' {aka 'struct fd'} has no member named 'file'
  835 |                 return getxattr(file_mnt_idmap(f.file), file_dentry(f.file),
      |                                                                      ^
fs/xattr.c: In function 'path_listxattrat':
fs/xattr.c:952:23: error: 'class_fd_t' {aka 'struct fd'} has no member named 'file'
  952 |                 if (!f.file)
      |                       ^
fs/xattr.c:954:29: error: 'class_fd_t' {aka 'struct fd'} has no member named 'file'
  954 |                 audit_file(f.file);
      |                             ^
fs/xattr.c:955:47: error: 'class_fd_t' {aka 'struct fd'} has no member named 'file'
  955 |                 return listxattr(file_dentry(f.file), list, size);
      |                                               ^
fs/xattr.c: In function 'do_fremovexattr':
fs/xattr.c:1021:15: error: 'class_fd_t' {aka 'struct fd'} has no member named 'file'
 1021 |         if (!f.file)
      |               ^
fs/xattr.c:1023:21: error: 'class_fd_t' {aka 'struct fd'} has no member named 'file'
 1023 |         audit_file(f.file);
      |                     ^
fs/xattr.c:1031:38: error: 'class_fd_t' {aka 'struct fd'} has no member named 'file'
 1031 |         error = mnt_want_write_file(f.file);
      |                                      ^
fs/xattr.c:1033:53: error: 'class_fd_t' {aka 'struct fd'} has no member named 'file'
 1033 |                 error = removexattr(file_mnt_idmap(f.file),
      |                                                     ^
fs/xattr.c:1034:38: error: 'class_fd_t' {aka 'struct fd'} has no member named 'file'
 1034 |                                     f.file->f_path.dentry, kname);
      |                                      ^
fs/xattr.c:1035:38: error: 'class_fd_t' {aka 'struct fd'} has no member named 'file'
 1035 |                 mnt_drop_write_file(f.file);
      |                                      ^

Caused by commit

  1da91ea87aef ("introduce fd_file(), convert all accessors to it.")

interacting with commits

  1a61c9d6ec1d ("xattr: handle AT_EMPTY_PATH when setting xattrs")
  278397b2c592 ("xattr: handle AT_EMPTY_PATH when getting xattrs")
  5560ab7ee32e ("xattr: handle AT_EMPTY_PATH when listing xattrs")
  33fce6444e7d ("xattr: handle AT_EMPTY_PATH when removing xattrs")

from the vfs-brauner tree.

I applied the following merge fix patch:

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Wed, 14 Aug 2024 11:20:43 +1000
Subject: [PATCH] fixup2 for "introduce fd_file(), convert all accessors to
 it."

interacting with

  1a61c9d6ec1d ("xattr: handle AT_EMPTY_PATH when setting xattrs")
  278397b2c592 ("xattr: handle AT_EMPTY_PATH when getting xattrs")
  5560ab7ee32e ("xattr: handle AT_EMPTY_PATH when listing xattrs")
  33fce6444e7d ("xattr: handle AT_EMPTY_PATH when removing xattrs")

from the vfs-brauner tree.

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 fs/xattr.c | 24 ++++++++++++------------
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/fs/xattr.c b/fs/xattr.c
index fa992953fa78..c0ecd0809172 100644
--- a/fs/xattr.c
+++ b/fs/xattr.c
@@ -829,10 +829,10 @@ static ssize_t path_getxattrat(int dfd, const char __user *pathname,
 
 	if (at_flags & AT_EMPTY_PATH && vfs_empty_path(dfd, pathname)) {
 		CLASS(fd, f)(dfd);
-		if (!f.file)
+		if (!fd_file(f))
 			return -EBADF;
-		audit_file(f.file);
-		return getxattr(file_mnt_idmap(f.file), file_dentry(f.file),
+		audit_file(fd_file(f));
+		return getxattr(file_mnt_idmap(fd_file(f)), file_dentry(fd_file(f)),
 				name, value, size);
 	}
 
@@ -949,10 +949,10 @@ static ssize_t path_listxattrat(int dfd, const char __user *pathname,
 
 	if (at_flags & AT_EMPTY_PATH && vfs_empty_path(dfd, pathname)) {
 		CLASS(fd, f)(dfd);
-		if (!f.file)
+		if (!fd_file(f))
 			return -EBADF;
-		audit_file(f.file);
-		return listxattr(file_dentry(f.file), list, size);
+		audit_file(fd_file(f));
+		return listxattr(file_dentry(fd_file(f)), list, size);
 	}
 
 	lookup_flags = (at_flags & AT_SYMLINK_NOFOLLOW) ? 0 : LOOKUP_FOLLOW;
@@ -1018,9 +1018,9 @@ static int do_fremovexattr(int fd, const char __user *name)
 	int error = -EBADF;
 
 	CLASS(fd, f)(fd);
-	if (!f.file)
+	if (!fd_file(f))
 		return error;
-	audit_file(f.file);
+	audit_file(fd_file(f));
 
 	error = strncpy_from_user(kname, name, sizeof(kname));
 	if (error == 0 || error == sizeof(kname))
@@ -1028,11 +1028,11 @@ static int do_fremovexattr(int fd, const char __user *name)
 	if (error < 0)
 		return error;
 
-	error = mnt_want_write_file(f.file);
+	error = mnt_want_write_file(fd_file(f));
 	if (!error) {
-		error = removexattr(file_mnt_idmap(f.file),
-				    f.file->f_path.dentry, kname);
-		mnt_drop_write_file(f.file);
+		error = removexattr(file_mnt_idmap(fd_file(f)),
+				    fd_file(f)->f_path.dentry, kname);
+		mnt_drop_write_file(fd_file(f));
 	}
 	return error;
 }
-- 
2.43.0

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Al Viro]

On Wed, Aug 14, 2024 at 11:25:04AM +1000, Stephen Rothwell wrote:
>  	if (at_flags & AT_EMPTY_PATH && vfs_empty_path(dfd, pathname)) {
>  		CLASS(fd, f)(dfd);
> -		if (!f.file)
> +		if (!fd_file(f))

		if (fd_empty(f))

actually, and similar for the rest of it.  Anyway, that'll need to be
sorted out in vfs/vfs.git; sorry about the delay.

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

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 4179 bytes --]

Hi Al,

On Wed, 14 Aug 2024 02:41:57 +0100 Al Viro <viro@zeniv.linux.org.uk> wrote:
>
> On Wed, Aug 14, 2024 at 11:25:04AM +1000, Stephen Rothwell wrote:
> >  	if (at_flags & AT_EMPTY_PATH && vfs_empty_path(dfd, pathname)) {
> >  		CLASS(fd, f)(dfd);
> > -		if (!f.file)
> > +		if (!fd_file(f))  
> 
> 		if (fd_empty(f))
> 
> actually, and similar for the rest of it.  Anyway, that'll need to be
> sorted out in vfs/vfs.git; sorry about the delay.

So from tomorrow, the two merge resolution patches will be these:

rom: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Wed, 14 Aug 2024 11:07:38 +1000
Subject: [PATCH] fixup for "introduce fd_file(), convert all accessors to it."

interacting with "fs: allow mount namespace fd" from the vfs-brauner tree.

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 fs/namespace.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/fs/namespace.c b/fs/namespace.c
index 159be8ed9d24..7aed325c48ad 100644
--- a/fs/namespace.c
+++ b/fs/namespace.c
@@ -5292,13 +5292,13 @@ static struct mnt_namespace *grab_requested_mnt_ns(const struct mnt_id_req *kreq
 		struct ns_common *ns;
 
 		CLASS(fd, f)(kreq->spare);
-		if (!f.file)
+		if (fd_empty(f))
 			return ERR_PTR(-EBADF);
 
-		if (!proc_ns_file(f.file))
+		if (!proc_ns_file(fd_file(f)))
 			return ERR_PTR(-EINVAL);
 
-		ns = get_proc_ns(file_inode(f.file));
+		ns = get_proc_ns(file_inode(fd_file(f)));
 		if (ns->ops->type != CLONE_NEWNS)
 			return ERR_PTR(-EINVAL);
 
-- 
2.43.0

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Wed, 14 Aug 2024 11:20:43 +1000
Subject: [PATCH] fixup2 for "introduce fd_file(), convert all accessors to it."

interacting with

  1a61c9d6ec1d ("xattr: handle AT_EMPTY_PATH when setting xattrs")
  278397b2c592 ("xattr: handle AT_EMPTY_PATH when getting xattrs")
  5560ab7ee32e ("xattr: handle AT_EMPTY_PATH when listing xattrs")
  33fce6444e7d ("xattr: handle AT_EMPTY_PATH when removing xattrs")

from the vfs-brauner tree.

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 fs/xattr.c | 24 ++++++++++++------------
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/fs/xattr.c b/fs/xattr.c
index fa992953fa78..c0ecd0809172 100644
--- a/fs/xattr.c
+++ b/fs/xattr.c
@@ -829,10 +829,10 @@ static ssize_t path_getxattrat(int dfd, const char __user *pathname,
 
 	if (at_flags & AT_EMPTY_PATH && vfs_empty_path(dfd, pathname)) {
 		CLASS(fd, f)(dfd);
-		if (!f.file)
+		if (fd_empty(f))
 			return -EBADF;
-		audit_file(f.file);
-		return getxattr(file_mnt_idmap(f.file), file_dentry(f.file),
+		audit_file(fd_file(f));
+		return getxattr(file_mnt_idmap(fd_file(f)), file_dentry(fd_file(f)),
 				name, value, size);
 	}
 
@@ -949,10 +949,10 @@ static ssize_t path_listxattrat(int dfd, const char __user *pathname,
 
 	if (at_flags & AT_EMPTY_PATH && vfs_empty_path(dfd, pathname)) {
 		CLASS(fd, f)(dfd);
-		if (!f.file)
+		if (fd_empty(f))
 			return -EBADF;
-		audit_file(f.file);
-		return listxattr(file_dentry(f.file), list, size);
+		audit_file(fd_file(f));
+		return listxattr(file_dentry(fd_file(f)), list, size);
 	}
 
 	lookup_flags = (at_flags & AT_SYMLINK_NOFOLLOW) ? 0 : LOOKUP_FOLLOW;
@@ -1018,9 +1018,9 @@ static int do_fremovexattr(int fd, const char __user *name)
 	int error = -EBADF;
 
 	CLASS(fd, f)(fd);
-	if (!f.file)
+	if (fd_empty(f))
 		return error;
-	audit_file(f.file);
+	audit_file(fd_file(f));
 
 	error = strncpy_from_user(kname, name, sizeof(kname));
 	if (error == 0 || error == sizeof(kname))
@@ -1028,11 +1028,11 @@ static int do_fremovexattr(int fd, const char __user *name)
 	if (error < 0)
 		return error;
 
-	error = mnt_want_write_file(f.file);
+	error = mnt_want_write_file(fd_file(f));
 	if (!error) {
-		error = removexattr(file_mnt_idmap(f.file),
-				    f.file->f_path.dentry, kname);
-		mnt_drop_write_file(f.file);
+		error = removexattr(file_mnt_idmap(fd_file(f)),
+				    fd_file(f)->f_path.dentry, kname);
+		mnt_drop_write_file(fd_file(f));
 	}
 	return error;
 }
-- 
2.43.0

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Christian Brauner]

On Wed, Aug 14, 2024 at 02:41:57AM GMT, Al Viro wrote:
> On Wed, Aug 14, 2024 at 11:25:04AM +1000, Stephen Rothwell wrote:
> >  	if (at_flags & AT_EMPTY_PATH && vfs_empty_path(dfd, pathname)) {
> >  		CLASS(fd, f)(dfd);
> > -		if (!f.file)
> > +		if (!fd_file(f))
> 
> 		if (fd_empty(f))
> 
> actually, and similar for the rest of it.  Anyway, that'll need to be
> sorted out in vfs/vfs.git; sorry about the delay.

You should already have a never rebase branch for the basic
infrastructure. I can just merge that. But I'll just make my usual note
and just provide the required fixups when I send Linus a pr. That'll
work too. /me trying not to have his brain melted by the heat.

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

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 680 bytes --]

Hi all,

On Wed, 14 Aug 2024 11:25:04 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Caused by commit
> 
>   1da91ea87aef ("introduce fd_file(), convert all accessors to it.")
> 
> interacting with commits
> 
>   1a61c9d6ec1d ("xattr: handle AT_EMPTY_PATH when setting xattrs")
>   278397b2c592 ("xattr: handle AT_EMPTY_PATH when getting xattrs")
>   5560ab7ee32e ("xattr: handle AT_EMPTY_PATH when listing xattrs")
>   33fce6444e7d ("xattr: handle AT_EMPTY_PATH when removing xattrs")
> 
> from the vfs-brauner tree.

It looks like he bpf-next tree has lost the above commit, so I have
removed my merge fix patches.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 2222 bytes --]

Hi all,

After merging the bpf-next tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:

fs/namespace.c: In function 'grab_requested_mnt_ns':
fs/namespace.c:5299:23: error: 'class_fd_t' {aka 'struct fd'} has no member named 'file'
 5299 |                 if (!f.file)
      |                       ^
fs/namespace.c:5302:36: error: 'class_fd_t' {aka 'struct fd'} has no member named 'file'
 5302 |                 if (!proc_ns_file(f.file))
      |                                    ^
In file included from fs/namespace.c:25:
fs/namespace.c:5305:46: error: 'class_fd_t' {aka 'struct fd'} has no member named 'file'
 5305 |                 ns = get_proc_ns(file_inode(f.file));
      |                                              ^
include/linux/proc_ns.h:75:50: note: in definition of macro 'get_proc_ns'
   75 | #define get_proc_ns(inode) ((struct ns_common *)(inode)->i_private)
      |                                                  ^~~~~

Caused by commit

  1da91ea87aef ("introduce fd_file(), convert all accessors to it.")

interacting with commit

  7b9d14af8777 ("fs: allow mount namespace fd")

-- 
Cheers,
Stephen Rothwell

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Fri, 13 Sep 2024 13:27:11 +1000
Subject: [PATCH] fixe up for "introduce fd_file(), convert all accessors to it."

interacting with "fs: allow mount namespace fd" from the vfs-brauner tree.

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 fs/namespace.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/fs/namespace.c b/fs/namespace.c
index 8e88938d3f19..cad6dd5db2da 100644
--- a/fs/namespace.c
+++ b/fs/namespace.c
@@ -5296,13 +5296,13 @@ static struct mnt_namespace *grab_requested_mnt_ns(const struct mnt_id_req *kreq
 		struct ns_common *ns;
 
 		CLASS(fd, f)(kreq->spare);
-		if (!f.file)
+		if (!fd_file(f))
 			return ERR_PTR(-EBADF);
 
-		if (!proc_ns_file(f.file))
+		if (!proc_ns_file(fd_file(f)))
 			return ERR_PTR(-EINVAL);
 
-		ns = get_proc_ns(file_inode(f.file));
+		ns = get_proc_ns(file_inode(fd_file(f)));
 		if (ns->ops->type != CLONE_NEWNS)
 			return ERR_PTR(-EINVAL);
 
-- 
2.45.2


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 4243 bytes --]

Hi all,

After merging the bpf-next tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:


Caused by commit

  1da91ea87aef ("introduce fd_file(), convert all accessors to it.")

interacting with commits

  1a61c9d6ec1d ("xattr: handle AT_EMPTY_PATH when setting xattrs")
  278397b2c592 ("xattr: handle AT_EMPTY_PATH when getting xattrs")
  5560ab7ee32e ("xattr: handle AT_EMPTY_PATH when listing xattrs")
  33fce6444e7d ("xattr: handle AT_EMPTY_PATH when removing xattrs")

I have applied the following patch for today.

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Fri, 13 Sep 2024 13:40:17 +1000
Subject: [PATCH] fix up 2 for "introduce fd_file(), convert all accessors to it."

interacting with commits

  1a61c9d6ec1d ("xattr: handle AT_EMPTY_PATH when setting xattrs")
  278397b2c592 ("xattr: handle AT_EMPTY_PATH when getting xattrs")
  5560ab7ee32e ("xattr: handle AT_EMPTY_PATH when listing xattrs")
  33fce6444e7d ("xattr: handle AT_EMPTY_PATH when removing xattrs")

from the vfs-brauner tree.

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 fs/xattr.c | 32 ++++++++++++++++----------------
 1 file changed, 16 insertions(+), 16 deletions(-)

diff --git a/fs/xattr.c b/fs/xattr.c
index fa992953fa78..f3559ed3279f 100644
--- a/fs/xattr.c
+++ b/fs/xattr.c
@@ -645,7 +645,7 @@ static int do_fsetxattr(int fd, const char __user *name,
 	int error;
 
 	CLASS(fd, f)(fd);
-	if (!fd_file(f))
+	if (fd_empty(f))
 		return -EBADF;
 
 	audit_file(fd_file(f));
@@ -829,10 +829,10 @@ static ssize_t path_getxattrat(int dfd, const char __user *pathname,
 
 	if (at_flags & AT_EMPTY_PATH && vfs_empty_path(dfd, pathname)) {
 		CLASS(fd, f)(dfd);
-		if (!f.file)
+		if (fd_empty(f))
 			return -EBADF;
-		audit_file(f.file);
-		return getxattr(file_mnt_idmap(f.file), file_dentry(f.file),
+		audit_file(fd_file(f));
+		return getxattr(file_mnt_idmap(fd_file(f)), file_dentry(fd_file(f)),
 				name, value, size);
 	}
 
@@ -895,7 +895,7 @@ SYSCALL_DEFINE4(fgetxattr, int, fd, const char __user *, name,
 	struct fd f = fdget(fd);
 	ssize_t error = -EBADF;
 
-	if (!fd_file(f))
+	if (fd_empty(f))
 		return error;
 	audit_file(fd_file(f));
 	error = getxattr(file_mnt_idmap(fd_file(f)), fd_file(f)->f_path.dentry,
@@ -949,10 +949,10 @@ static ssize_t path_listxattrat(int dfd, const char __user *pathname,
 
 	if (at_flags & AT_EMPTY_PATH && vfs_empty_path(dfd, pathname)) {
 		CLASS(fd, f)(dfd);
-		if (!f.file)
+		if (fd_empty(f))
 			return -EBADF;
-		audit_file(f.file);
-		return listxattr(file_dentry(f.file), list, size);
+		audit_file(fd_file(f));
+		return listxattr(file_dentry(fd_file(f)), list, size);
 	}
 
 	lookup_flags = (at_flags & AT_SYMLINK_NOFOLLOW) ? 0 : LOOKUP_FOLLOW;
@@ -993,7 +993,7 @@ SYSCALL_DEFINE3(flistxattr, int, fd, char __user *, list, size_t, size)
 	struct fd f = fdget(fd);
 	ssize_t error = -EBADF;
 
-	if (!fd_file(f))
+	if (fd_empty(f))
 		return error;
 	audit_file(fd_file(f));
 	error = listxattr(fd_file(f)->f_path.dentry, list, size);
@@ -1018,9 +1018,9 @@ static int do_fremovexattr(int fd, const char __user *name)
 	int error = -EBADF;
 
 	CLASS(fd, f)(fd);
-	if (!f.file)
+	if (fd_empty(f))
 		return error;
-	audit_file(f.file);
+	audit_file(fd_file(f));
 
 	error = strncpy_from_user(kname, name, sizeof(kname));
 	if (error == 0 || error == sizeof(kname))
@@ -1028,11 +1028,11 @@ static int do_fremovexattr(int fd, const char __user *name)
 	if (error < 0)
 		return error;
 
-	error = mnt_want_write_file(f.file);
+	error = mnt_want_write_file(fd_file(f));
 	if (!error) {
-		error = removexattr(file_mnt_idmap(f.file),
-				    f.file->f_path.dentry, kname);
-		mnt_drop_write_file(f.file);
+		error = removexattr(file_mnt_idmap(fd_file(f)),
+				    fd_file(f)->f_path.dentry, kname);
+		mnt_drop_write_file(fd_file(f));
 	}
 	return error;
 }
@@ -1099,7 +1099,7 @@ SYSCALL_DEFINE2(fremovexattr, int, fd, const char __user *, name)
 	char kname[XATTR_NAME_MAX + 1];
 	int error = -EBADF;
 
-	if (!fd_file(f))
+	if (fd_empty(f))
 		return error;
 	audit_file(fd_file(f));
 
-- 
2.45.2

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 7493 bytes --]

Hi all,

On Fri, 13 Sep 2024 13:45:04 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> After merging the bpf-next tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:

/home/sfr/next/next/fs/xattr.c: In function 'path_getxattrat':
/home/sfr/next/next/fs/xattr.c:832:23: error: 'class_fd_t' {aka 'struct fd'} has no member named 'file'
  832 |                 if (!f.file)
      |                       ^
/home/sfr/next/next/fs/xattr.c:834:29: error: 'class_fd_t' {aka 'struct fd'} has no member named 'file'
  834 |                 audit_file(f.file);
      |                             ^
/home/sfr/next/next/fs/xattr.c:835:49: error: 'class_fd_t' {aka 'struct fd'} has no member named 'file'
  835 |                 return getxattr(file_mnt_idmap(f.file), file_dentry(f.file),
      |                                                 ^
/home/sfr/next/next/fs/xattr.c:835:70: error: 'class_fd_t' {aka 'struct fd'} has no member named 'file'
  835 |                 return getxattr(file_mnt_idmap(f.file), file_dentry(f.file),
      |                                                                      ^
/home/sfr/next/next/fs/xattr.c: In function 'path_listxattrat':
/home/sfr/next/next/fs/xattr.c:952:23: error: 'class_fd_t' {aka 'struct fd'} has no member named 'file'
  952 |                 if (!f.file)
      |                       ^
/home/sfr/next/next/fs/xattr.c:954:29: error: 'class_fd_t' {aka 'struct fd'} has no member named 'file'
  954 |                 audit_file(f.file);
      |                             ^
/home/sfr/next/next/fs/xattr.c:955:47: error: 'class_fd_t' {aka 'struct fd'} has no member named 'file'
  955 |                 return listxattr(file_dentry(f.file), list, size);
      |                                               ^
/home/sfr/next/next/fs/xattr.c: In function 'do_fremovexattr':
/home/sfr/next/next/fs/xattr.c:1021:15: error: 'class_fd_t' {aka 'struct fd'} has no member named 'file'
 1021 |         if (!f.file) 
      |               ^
/home/sfr/next/next/fs/xattr.c:1023:21: error: 'class_fd_t' {aka 'struct fd'} has no member named 'file'
 1023 |         audit_file(f.file);
      |                     ^
/home/sfr/next/next/fs/xattr.c:1031:38: error: 'class_fd_t' {aka 'struct fd'} has no member named 'file'
 1031 |         error = mnt_want_write_file(f.file);
      |                                      ^
/home/sfr/next/next/fs/xattr.c:1033:53: error: 'class_fd_t' {aka 'struct fd'} has no member named 'file'
 1033 |                 error = removexattr(file_mnt_idmap(f.file),
      |                                                     ^
/home/sfr/next/next/fs/xattr.c:1034:38: error: 'class_fd_t' {aka 'struct fd'} has no member named 'file'
 1034 |                                     f.file->f_path.dentry, kname);
      |                                      ^
/home/sfr/next/next/fs/xattr.c:1035:38: error: 'class_fd_t' {aka 'struct fd'} has no member named 'file'
 1035 |                 mnt_drop_write_file(f.file);
      |                                      ^

> Caused by commit
> 
>   1da91ea87aef ("introduce fd_file(), convert all accessors to it.")
> 
> interacting with commits
> 
>   1a61c9d6ec1d ("xattr: handle AT_EMPTY_PATH when setting xattrs")
>   278397b2c592 ("xattr: handle AT_EMPTY_PATH when getting xattrs")
>   5560ab7ee32e ("xattr: handle AT_EMPTY_PATH when listing xattrs")
>   33fce6444e7d ("xattr: handle AT_EMPTY_PATH when removing xattrs")
> 
> I have applied the following patch for today.
> 
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Fri, 13 Sep 2024 13:40:17 +1000
> Subject: [PATCH] fix up 2 for "introduce fd_file(), convert all accessors to it."
> 
> interacting with commits
> 
>   1a61c9d6ec1d ("xattr: handle AT_EMPTY_PATH when setting xattrs")
>   278397b2c592 ("xattr: handle AT_EMPTY_PATH when getting xattrs")
>   5560ab7ee32e ("xattr: handle AT_EMPTY_PATH when listing xattrs")
>   33fce6444e7d ("xattr: handle AT_EMPTY_PATH when removing xattrs")
> 
> from the vfs-brauner tree.
> 
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
>  fs/xattr.c | 32 ++++++++++++++++----------------
>  1 file changed, 16 insertions(+), 16 deletions(-)
> 
> diff --git a/fs/xattr.c b/fs/xattr.c
> index fa992953fa78..f3559ed3279f 100644
> --- a/fs/xattr.c
> +++ b/fs/xattr.c
> @@ -645,7 +645,7 @@ static int do_fsetxattr(int fd, const char __user *name,
>  	int error;
>  
>  	CLASS(fd, f)(fd);
> -	if (!fd_file(f))
> +	if (fd_empty(f))
>  		return -EBADF;
>  
>  	audit_file(fd_file(f));
> @@ -829,10 +829,10 @@ static ssize_t path_getxattrat(int dfd, const char __user *pathname,
>  
>  	if (at_flags & AT_EMPTY_PATH && vfs_empty_path(dfd, pathname)) {
>  		CLASS(fd, f)(dfd);
> -		if (!f.file)
> +		if (fd_empty(f))
>  			return -EBADF;
> -		audit_file(f.file);
> -		return getxattr(file_mnt_idmap(f.file), file_dentry(f.file),
> +		audit_file(fd_file(f));
> +		return getxattr(file_mnt_idmap(fd_file(f)), file_dentry(fd_file(f)),
>  				name, value, size);
>  	}
>  
> @@ -895,7 +895,7 @@ SYSCALL_DEFINE4(fgetxattr, int, fd, const char __user *, name,
>  	struct fd f = fdget(fd);
>  	ssize_t error = -EBADF;
>  
> -	if (!fd_file(f))
> +	if (fd_empty(f))
>  		return error;
>  	audit_file(fd_file(f));
>  	error = getxattr(file_mnt_idmap(fd_file(f)), fd_file(f)->f_path.dentry,
> @@ -949,10 +949,10 @@ static ssize_t path_listxattrat(int dfd, const char __user *pathname,
>  
>  	if (at_flags & AT_EMPTY_PATH && vfs_empty_path(dfd, pathname)) {
>  		CLASS(fd, f)(dfd);
> -		if (!f.file)
> +		if (fd_empty(f))
>  			return -EBADF;
> -		audit_file(f.file);
> -		return listxattr(file_dentry(f.file), list, size);
> +		audit_file(fd_file(f));
> +		return listxattr(file_dentry(fd_file(f)), list, size);
>  	}
>  
>  	lookup_flags = (at_flags & AT_SYMLINK_NOFOLLOW) ? 0 : LOOKUP_FOLLOW;
> @@ -993,7 +993,7 @@ SYSCALL_DEFINE3(flistxattr, int, fd, char __user *, list, size_t, size)
>  	struct fd f = fdget(fd);
>  	ssize_t error = -EBADF;
>  
> -	if (!fd_file(f))
> +	if (fd_empty(f))
>  		return error;
>  	audit_file(fd_file(f));
>  	error = listxattr(fd_file(f)->f_path.dentry, list, size);
> @@ -1018,9 +1018,9 @@ static int do_fremovexattr(int fd, const char __user *name)
>  	int error = -EBADF;
>  
>  	CLASS(fd, f)(fd);
> -	if (!f.file)
> +	if (fd_empty(f))
>  		return error;
> -	audit_file(f.file);
> +	audit_file(fd_file(f));
>  
>  	error = strncpy_from_user(kname, name, sizeof(kname));
>  	if (error == 0 || error == sizeof(kname))
> @@ -1028,11 +1028,11 @@ static int do_fremovexattr(int fd, const char __user *name)
>  	if (error < 0)
>  		return error;
>  
> -	error = mnt_want_write_file(f.file);
> +	error = mnt_want_write_file(fd_file(f));
>  	if (!error) {
> -		error = removexattr(file_mnt_idmap(f.file),
> -				    f.file->f_path.dentry, kname);
> -		mnt_drop_write_file(f.file);
> +		error = removexattr(file_mnt_idmap(fd_file(f)),
> +				    fd_file(f)->f_path.dentry, kname);
> +		mnt_drop_write_file(fd_file(f));
>  	}
>  	return error;
>  }
> @@ -1099,7 +1099,7 @@ SYSCALL_DEFINE2(fremovexattr, int, fd, const char __user *, name)
>  	char kname[XATTR_NAME_MAX + 1];
>  	int error = -EBADF;
>  
> -	if (!fd_file(f))
> +	if (fd_empty(f))
>  		return error;
>  	audit_file(fd_file(f));
>  
> -- 
> 2.45.2

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1645 bytes --]

Hi all,

After merging the bpf-next tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:

fs/xfs/xfs_exchrange.c: In function 'xfs_ioc_commit_range':
fs/xfs/xfs_exchrange.c:938:19: error: 'struct fd' has no member named 'file'
  938 |         if (!file1.file)
      |                   ^
fs/xfs/xfs_exchrange.c:940:26: error: 'struct fd' has no member named 'file'
  940 |         fxr.file1 = file1.file;
      |                          ^

Caused by commit

  1da91ea87aef ("introduce fd_file(), convert all accessors to it.")

interacting with commit

  398597c3ef7f ("xfs: introduce new file range commit ioctls")

I have applied the following patch for today.

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Fri, 13 Sep 2024 13:53:35 +1000
Subject: [PATCH] fix up 3 for "introduce fd_file(), convert all accessors to
 it."

interacting with commit "xfs: introduce new file range commit ioctls"
from the xfs tree.

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 fs/xfs/xfs_exchrange.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/fs/xfs/xfs_exchrange.c b/fs/xfs/xfs_exchrange.c
index 39fe02a8deac..75cb53f090d1 100644
--- a/fs/xfs/xfs_exchrange.c
+++ b/fs/xfs/xfs_exchrange.c
@@ -935,9 +935,9 @@ xfs_ioc_commit_range(
 	fxr.file2_ctime.tv_nsec	= kern_f->file2_ctime_nsec;
 
 	file1 = fdget(args.file1_fd);
-	if (!file1.file)
+	if (fd_empty(file1))
 		return -EBADF;
-	fxr.file1 = file1.file;
+	fxr.file1 = fd_file(file1);
 
 	error = xfs_exchange_range(&fxr);
 	fdput(file1);
-- 
2.45.2

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Al Viro]

On Fri, Sep 13, 2024 at 01:55:51PM +1000, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the bpf-next tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
> 
> fs/xfs/xfs_exchrange.c: In function 'xfs_ioc_commit_range':
> fs/xfs/xfs_exchrange.c:938:19: error: 'struct fd' has no member named 'file'
>   938 |         if (!file1.file)
>       |                   ^
> fs/xfs/xfs_exchrange.c:940:26: error: 'struct fd' has no member named 'file'
>   940 |         fxr.file1 = file1.file;
>       |                          ^
> 
> Caused by commit
> 
>   1da91ea87aef ("introduce fd_file(), convert all accessors to it.")
> 
> interacting with commit
> 
>   398597c3ef7f ("xfs: introduce new file range commit ioctls")
> 
> I have applied the following patch for today.
> 
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Fri, 13 Sep 2024 13:53:35 +1000
> Subject: [PATCH] fix up 3 for "introduce fd_file(), convert all accessors to
>  it."
> 
> interacting with commit "xfs: introduce new file range commit ioctls"
> from the xfs tree.

... and the same for io_uring/rsrc.c, conflict with "io_uring: add IORING_REGISTER_COPY_BUFFERS method".

FWIW, that (sub)series is in viro/vfs.git#for-next - I forgot to put it
there, so when bpf tree reorgs had lost their branch on top of that thing,
the conflict fixes got dropped from -next.  Sorry... ;-/

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

[Andrii Nakryiko]

On Thu, Sep 12, 2024 at 9:00 PM Al Viro <viro@zeniv.linux.org.uk> wrote:
>
> On Fri, Sep 13, 2024 at 01:55:51PM +1000, Stephen Rothwell wrote:
> > Hi all,
> >
> > After merging the bpf-next tree, today's linux-next build (powerpc
> > ppc64_defconfig) failed like this:
> >
> > fs/xfs/xfs_exchrange.c: In function 'xfs_ioc_commit_range':
> > fs/xfs/xfs_exchrange.c:938:19: error: 'struct fd' has no member named 'file'
> >   938 |         if (!file1.file)
> >       |                   ^
> > fs/xfs/xfs_exchrange.c:940:26: error: 'struct fd' has no member named 'file'
> >   940 |         fxr.file1 = file1.file;
> >       |                          ^
> >
> > Caused by commit
> >
> >   1da91ea87aef ("introduce fd_file(), convert all accessors to it.")
> >
> > interacting with commit
> >
> >   398597c3ef7f ("xfs: introduce new file range commit ioctls")
> >
> > I have applied the following patch for today.
> >
> > From: Stephen Rothwell <sfr@canb.auug.org.au>
> > Date: Fri, 13 Sep 2024 13:53:35 +1000
> > Subject: [PATCH] fix up 3 for "introduce fd_file(), convert all accessors to
> >  it."
> >
> > interacting with commit "xfs: introduce new file range commit ioctls"
> > from the xfs tree.
>
> ... and the same for io_uring/rsrc.c, conflict with "io_uring: add IORING_REGISTER_COPY_BUFFERS method".
>
> FWIW, that (sub)series is in viro/vfs.git#for-next - I forgot to put it
> there, so when bpf tree reorgs had lost their branch on top of that thing,
> the conflict fixes got dropped from -next.  Sorry... ;-/

Should I take out the following from bpf-next/for-next for now?

a8e40fd0f127 ("Merge branch 'bpf-next/struct_fd' into for-next")

Al, currently I'm basing my patches on top of your stable-struct_fd
branch. If you need to update it, I think that's fine, I can rebase on
top of the updated branch, given my patches weren't yet merged
anywhere. Let me know.

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

[Al Viro]

On Thu, Sep 12, 2024 at 09:26:31PM -0700, Andrii Nakryiko wrote:

> Should I take out the following from bpf-next/for-next for now?
> 
> a8e40fd0f127 ("Merge branch 'bpf-next/struct_fd' into for-next")
> 
> Al, currently I'm basing my patches on top of your stable-struct_fd
> branch. If you need to update it, I think that's fine, I can rebase on
> top of the updated branch, given my patches weren't yet merged
> anywhere. Let me know.

al@duke:~/linux/trees/temp$ git describe for-next 
v6.11-rc1-3-gde12c3391bce
al@duke:~/linux/trees/temp$ git describe stable-struct_fd 
v6.11-rc1-3-gde12c3391bce

IOW, #for-next is currently identical to that branch (will grow a merge
shortly); no need to rebase anything.

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

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 2526 bytes --]

Hi all,

On Fri, 13 Sep 2024 13:32:40 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> After merging the bpf-next tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
> 
> fs/namespace.c: In function 'grab_requested_mnt_ns':
> fs/namespace.c:5299:23: error: 'class_fd_t' {aka 'struct fd'} has no member named 'file'
>  5299 |                 if (!f.file)
>       |                       ^
> fs/namespace.c:5302:36: error: 'class_fd_t' {aka 'struct fd'} has no member named 'file'
>  5302 |                 if (!proc_ns_file(f.file))
>       |                                    ^
> In file included from fs/namespace.c:25:
> fs/namespace.c:5305:46: error: 'class_fd_t' {aka 'struct fd'} has no member named 'file'
>  5305 |                 ns = get_proc_ns(file_inode(f.file));
>       |                                              ^
> include/linux/proc_ns.h:75:50: note: in definition of macro 'get_proc_ns'
>    75 | #define get_proc_ns(inode) ((struct ns_common *)(inode)->i_private)
>       |                                                  ^~~~~
> 
> Caused by commit
> 
>   1da91ea87aef ("introduce fd_file(), convert all accessors to it.")
> 
> interacting with commit
> 
>   7b9d14af8777 ("fs: allow mount namespace fd")
> 
> -- 
> Cheers,
> Stephen Rothwell
> 
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Fri, 13 Sep 2024 13:27:11 +1000
> Subject: [PATCH] fixe up for "introduce fd_file(), convert all accessors to it."
> 
> interacting with "fs: allow mount namespace fd" from the vfs-brauner tree.
> 
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
>  fs/namespace.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/fs/namespace.c b/fs/namespace.c
> index 8e88938d3f19..cad6dd5db2da 100644
> --- a/fs/namespace.c
> +++ b/fs/namespace.c
> @@ -5296,13 +5296,13 @@ static struct mnt_namespace *grab_requested_mnt_ns(const struct mnt_id_req *kreq
>  		struct ns_common *ns;
>  
>  		CLASS(fd, f)(kreq->spare);
> -		if (!f.file)
> +		if (!fd_file(f))
>  			return ERR_PTR(-EBADF);
>  
> -		if (!proc_ns_file(f.file))
> +		if (!proc_ns_file(fd_file(f)))
>  			return ERR_PTR(-EINVAL);
>  
> -		ns = get_proc_ns(file_inode(f.file));
> +		ns = get_proc_ns(file_inode(fd_file(f)));
>  		if (ns->ops->type != CLONE_NEWNS)
>  			return ERR_PTR(-EINVAL);
>  
> -- 
> 2.45.2
> 

This is now required in the merge of the vfs tree.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 4693 bytes --]

Hi all,

On Fri, 13 Sep 2024 13:45:04 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> After merging the bpf-next tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
> 
> 
> Caused by commit
> 
>   1da91ea87aef ("introduce fd_file(), convert all accessors to it.")
> 
> interacting with commits
> 
>   1a61c9d6ec1d ("xattr: handle AT_EMPTY_PATH when setting xattrs")
>   278397b2c592 ("xattr: handle AT_EMPTY_PATH when getting xattrs")
>   5560ab7ee32e ("xattr: handle AT_EMPTY_PATH when listing xattrs")
>   33fce6444e7d ("xattr: handle AT_EMPTY_PATH when removing xattrs")
> 
> I have applied the following patch for today.
> 
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Fri, 13 Sep 2024 13:40:17 +1000
> Subject: [PATCH] fix up 2 for "introduce fd_file(), convert all accessors to it."
> 
> interacting with commits
> 
>   1a61c9d6ec1d ("xattr: handle AT_EMPTY_PATH when setting xattrs")
>   278397b2c592 ("xattr: handle AT_EMPTY_PATH when getting xattrs")
>   5560ab7ee32e ("xattr: handle AT_EMPTY_PATH when listing xattrs")
>   33fce6444e7d ("xattr: handle AT_EMPTY_PATH when removing xattrs")
> 
> from the vfs-brauner tree.
> 
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
>  fs/xattr.c | 32 ++++++++++++++++----------------
>  1 file changed, 16 insertions(+), 16 deletions(-)
> 
> diff --git a/fs/xattr.c b/fs/xattr.c
> index fa992953fa78..f3559ed3279f 100644
> --- a/fs/xattr.c
> +++ b/fs/xattr.c
> @@ -645,7 +645,7 @@ static int do_fsetxattr(int fd, const char __user *name,
>  	int error;
>  
>  	CLASS(fd, f)(fd);
> -	if (!fd_file(f))
> +	if (fd_empty(f))
>  		return -EBADF;
>  
>  	audit_file(fd_file(f));
> @@ -829,10 +829,10 @@ static ssize_t path_getxattrat(int dfd, const char __user *pathname,
>  
>  	if (at_flags & AT_EMPTY_PATH && vfs_empty_path(dfd, pathname)) {
>  		CLASS(fd, f)(dfd);
> -		if (!f.file)
> +		if (fd_empty(f))
>  			return -EBADF;
> -		audit_file(f.file);
> -		return getxattr(file_mnt_idmap(f.file), file_dentry(f.file),
> +		audit_file(fd_file(f));
> +		return getxattr(file_mnt_idmap(fd_file(f)), file_dentry(fd_file(f)),
>  				name, value, size);
>  	}
>  
> @@ -895,7 +895,7 @@ SYSCALL_DEFINE4(fgetxattr, int, fd, const char __user *, name,
>  	struct fd f = fdget(fd);
>  	ssize_t error = -EBADF;
>  
> -	if (!fd_file(f))
> +	if (fd_empty(f))
>  		return error;
>  	audit_file(fd_file(f));
>  	error = getxattr(file_mnt_idmap(fd_file(f)), fd_file(f)->f_path.dentry,
> @@ -949,10 +949,10 @@ static ssize_t path_listxattrat(int dfd, const char __user *pathname,
>  
>  	if (at_flags & AT_EMPTY_PATH && vfs_empty_path(dfd, pathname)) {
>  		CLASS(fd, f)(dfd);
> -		if (!f.file)
> +		if (fd_empty(f))
>  			return -EBADF;
> -		audit_file(f.file);
> -		return listxattr(file_dentry(f.file), list, size);
> +		audit_file(fd_file(f));
> +		return listxattr(file_dentry(fd_file(f)), list, size);
>  	}
>  
>  	lookup_flags = (at_flags & AT_SYMLINK_NOFOLLOW) ? 0 : LOOKUP_FOLLOW;
> @@ -993,7 +993,7 @@ SYSCALL_DEFINE3(flistxattr, int, fd, char __user *, list, size_t, size)
>  	struct fd f = fdget(fd);
>  	ssize_t error = -EBADF;
>  
> -	if (!fd_file(f))
> +	if (fd_empty(f))
>  		return error;
>  	audit_file(fd_file(f));
>  	error = listxattr(fd_file(f)->f_path.dentry, list, size);
> @@ -1018,9 +1018,9 @@ static int do_fremovexattr(int fd, const char __user *name)
>  	int error = -EBADF;
>  
>  	CLASS(fd, f)(fd);
> -	if (!f.file)
> +	if (fd_empty(f))
>  		return error;
> -	audit_file(f.file);
> +	audit_file(fd_file(f));
>  
>  	error = strncpy_from_user(kname, name, sizeof(kname));
>  	if (error == 0 || error == sizeof(kname))
> @@ -1028,11 +1028,11 @@ static int do_fremovexattr(int fd, const char __user *name)
>  	if (error < 0)
>  		return error;
>  
> -	error = mnt_want_write_file(f.file);
> +	error = mnt_want_write_file(fd_file(f));
>  	if (!error) {
> -		error = removexattr(file_mnt_idmap(f.file),
> -				    f.file->f_path.dentry, kname);
> -		mnt_drop_write_file(f.file);
> +		error = removexattr(file_mnt_idmap(fd_file(f)),
> +				    fd_file(f)->f_path.dentry, kname);
> +		mnt_drop_write_file(fd_file(f));
>  	}
>  	return error;
>  }
> @@ -1099,7 +1099,7 @@ SYSCALL_DEFINE2(fremovexattr, int, fd, const char __user *, name)
>  	char kname[XATTR_NAME_MAX + 1];
>  	int error = -EBADF;
>  
> -	if (!fd_file(f))
> +	if (fd_empty(f))
>  		return error;
>  	audit_file(fd_file(f));
>  
> -- 
> 2.45.2

This is not longer required as the above commits have been removed from
the vfs-brauner tree.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1887 bytes --]

Hi all,

On Fri, 13 Sep 2024 13:55:51 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> After merging the bpf-next tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
> 
> fs/xfs/xfs_exchrange.c: In function 'xfs_ioc_commit_range':
> fs/xfs/xfs_exchrange.c:938:19: error: 'struct fd' has no member named 'file'
>   938 |         if (!file1.file)
>       |                   ^
> fs/xfs/xfs_exchrange.c:940:26: error: 'struct fd' has no member named 'file'
>   940 |         fxr.file1 = file1.file;
>       |                          ^
> 
> Caused by commit
> 
>   1da91ea87aef ("introduce fd_file(), convert all accessors to it.")
> 
> interacting with commit
> 
>   398597c3ef7f ("xfs: introduce new file range commit ioctls")
> 
> I have applied the following patch for today.
> 
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Fri, 13 Sep 2024 13:53:35 +1000
> Subject: [PATCH] fix up 3 for "introduce fd_file(), convert all accessors to
>  it."
> 
> interacting with commit "xfs: introduce new file range commit ioctls"
> from the xfs tree.
> 
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
>  fs/xfs/xfs_exchrange.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/fs/xfs/xfs_exchrange.c b/fs/xfs/xfs_exchrange.c
> index 39fe02a8deac..75cb53f090d1 100644
> --- a/fs/xfs/xfs_exchrange.c
> +++ b/fs/xfs/xfs_exchrange.c
> @@ -935,9 +935,9 @@ xfs_ioc_commit_range(
>  	fxr.file2_ctime.tv_nsec	= kern_f->file2_ctime_nsec;
>  
>  	file1 = fdget(args.file1_fd);
> -	if (!file1.file)
> +	if (fd_empty(file1))
>  		return -EBADF;
> -	fxr.file1 = file1.file;
> +	fxr.file1 = fd_file(file1);
>  
>  	error = xfs_exchange_range(&fxr);
>  	fdput(file1);
> -- 
> 2.45.2

This is now required in the merge of the vfs tree.
-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1809 bytes --]

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.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Alexei Starovoitov]

On Tue, Oct 15, 2024 at 11:05 PM Stephen Rothwell <sfr@canb.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.

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

[Namhyung Kim]

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@canb.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.

Thanks,
Namhyung

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

[Alexei Starovoitov]

On Wed, Oct 16, 2024 at 11:35 AM Namhyung Kim <namhyung@kernel.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@canb.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.

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

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 5745 bytes --]

Hi all,

After merging the bpf-next tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:

In file included from include/asm-generic/percpu.h:7,
                 from arch/powerpc/include/asm/percpu.h:28,
                 from arch/powerpc/include/asm/smp.h:26,
                 from include/linux/smp.h:119,
                 from include/linux/lockdep.h:14,
                 from include/linux/radix-tree.h:14,
                 from include/linux/idr.h:15,
                 from include/linux/cgroup-defs.h:13,
                 from mm/memcontrol.c:28:
mm/memcontrol.c: In function 'memcg_hotplug_cpu_dead':
include/linux/percpu-defs.h:242:2: error: passing argument 1 of 'local_lock_acquire' from incompatible pointer type [-Wincompatible-pointer-types]
  242 | ({                                                                      \
      | ~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      |  |
      |  localtry_lock_t *
  243 |         __verify_pcpu_ptr(ptr);                                         \
      |         ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  244 |         arch_raw_cpu_ptr(ptr);                                          \
      |         ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  245 | })
      | ~~
include/linux/percpu-defs.h:254:27: note: in expansion of macro 'raw_cpu_ptr'
  254 | #define this_cpu_ptr(ptr) raw_cpu_ptr(ptr)
      |                           ^~~~~~~~~~~
include/linux/local_lock_internal.h:105:36: note: in expansion of macro 'this_cpu_ptr'
  105 |                 local_lock_acquire(this_cpu_ptr(lock));         \
      |                                    ^~~~~~~~~~~~
include/linux/local_lock.h:31:9: note: in expansion of macro '__local_lock_irqsave'
   31 |         __local_lock_irqsave(lock, flags)
      |         ^~~~~~~~~~~~~~~~~~~~
mm/memcontrol.c:1960:9: note: in expansion of macro 'local_lock_irqsave'
 1960 |         local_lock_irqsave(&memcg_stock.stock_lock, flags);
      |         ^~~~~~~~~~~~~~~~~~
In file included from include/linux/local_lock.h:5,
                 from include/linux/mmzone.h:24,
                 from include/linux/gfp.h:7,
                 from include/linux/xarray.h:16,
                 from include/linux/radix-tree.h:21:
include/linux/local_lock_internal.h:59:53: note: expected 'local_lock_t *' but argument is of type 'localtry_lock_t *'
   59 | static inline void local_lock_acquire(local_lock_t *l) { }
      |                                       ~~~~~~~~~~~~~~^
include/linux/percpu-defs.h:242:2: error: passing argument 1 of 'local_lock_release' from incompatible pointer type [-Wincompatible-pointer-types]
  242 | ({                                                                      \
      | ~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      |  |
      |  localtry_lock_t *
  243 |         __verify_pcpu_ptr(ptr);                                         \
      |         ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  244 |         arch_raw_cpu_ptr(ptr);                                          \
      |         ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  245 | })
      | ~~
include/linux/percpu-defs.h:254:27: note: in expansion of macro 'raw_cpu_ptr'
  254 | #define this_cpu_ptr(ptr) raw_cpu_ptr(ptr)
      |                           ^~~~~~~~~~~
include/linux/local_lock_internal.h:122:36: note: in expansion of macro 'this_cpu_ptr'
  122 |                 local_lock_release(this_cpu_ptr(lock));         \
      |                                    ^~~~~~~~~~~~
include/linux/local_lock.h:52:9: note: in expansion of macro '__local_unlock_irqrestore'
   52 |         __local_unlock_irqrestore(lock, flags)
      |         ^~~~~~~~~~~~~~~~~~~~~~~~~
mm/memcontrol.c:1962:9: note: in expansion of macro 'local_unlock_irqrestore'
 1962 |         local_unlock_irqrestore(&memcg_stock.stock_lock, flags);
      |         ^~~~~~~~~~~~~~~~~~~~~~~
include/linux/local_lock_internal.h:61:53: note: expected 'local_lock_t *' but argument is of type 'localtry_lock_t *'
   61 | static inline void local_lock_release(local_lock_t *l) { }
      |                                       ~~~~~~~~~~~~~~^

Caused by commits

  0aaddfb06882 ("locking/local_lock: Introduce localtry_lock_t")
  01d37228d331 ("memcg: Use trylock to access memcg stock_lock.")

interacting with commit

  885aa5fe7b1d ("memcg: drain obj stock on cpu hotplug teardown")

from the mm-hotfixes tree.

I applied the following merge fix patch.

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Wed, 12 Mar 2025 14:18:03 +1100
Subject: [PATCH] fix up for "memcg: Use trylock to access memcg stock_lock"

interacting with "memcg: drain obj stock on cpu hotplug teardown" from
the mm-hotfixes tree.

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 mm/memcontrol.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index 8f88b8dd8097..87544df4c3b8 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -1957,9 +1957,9 @@ static int memcg_hotplug_cpu_dead(unsigned int cpu)
 	stock = &per_cpu(memcg_stock, cpu);
 
 	/* drain_obj_stock requires stock_lock */
-	local_lock_irqsave(&memcg_stock.stock_lock, flags);
+	localtry_lock_irqsave(&memcg_stock.stock_lock, flags);
 	old = drain_obj_stock(stock);
-	local_unlock_irqrestore(&memcg_stock.stock_lock, flags);
+	localtry_unlock_irqrestore(&memcg_stock.stock_lock, flags);
 
 	drain_stock(stock);
 	obj_cgroup_put(old);
-- 
2.45.2

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 3434 bytes --]

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.

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.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Alexei Starovoitov]

On Tue, Mar 18, 2025 at 7:33 PM Stephen Rothwell <sfr@canb.auug.org.au> 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@gmail.com/

>
> 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.

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

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 705 bytes --]

Hi Alexei,

On Tue, 18 Mar 2025 19:46:52 -0700 Alexei Starovoitov <alexei.starovoitov@gmail.com> wrote:
>
> > 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@gmail.com/

Yes.  Also available as commits up to commit

 6a367577153a ("percpu/x86: enable strict percpu checks via named AS qualifiers")

in the mm-stable branch of the mm tree
(git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm#mm-stable) and
yesterday's linux-next tree.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Uros Bizjak]

On Wed, Mar 19, 2025 at 3:33 AM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> 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.
>
> 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.

percpu pointers are now checked by the compiler, and their address
spaces have to be handled properly. It is like "sparse" rule, but now
enforced by the compiler.

This functionality was in fact introduced to catch programming errors like this.

Thanks,
Uros.

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

[Kumar Kartikeya Dwivedi]

On Wed, 19 Mar 2025 at 03:47, Alexei Starovoitov
<alexei.starovoitov@gmail.com> wrote:
>
> On Tue, Mar 18, 2025 at 7:33 PM Stephen Rothwell <sfr@canb.auug.org.au> 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@gmail.com/
>
> >
> > 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.

[0] https://lore.kernel.org/bpf/20250319133523.641009-1-memxor@gmail.com

Feel free to cherry-pick or squash into the fixed commit, whatever is best.

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@gmail.com> wrote:
>
> On Wed, 19 Mar 2025 at 03:47, Alexei Starovoitov
> <alexei.starovoitov@gmail.com> wrote:
> >
> > On Tue, Mar 18, 2025 at 7:33 PM Stephen Rothwell <sfr@canb.auug.org.au> 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@gmail.com/
> >
> > >
> > > 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@gmail.com
>
> Feel free to cherry-pick or squash into the fixed commit, whatever is best.

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

[Kumar Kartikeya Dwivedi]

On Wed, 19 Mar 2025 at 14:43, Kumar Kartikeya Dwivedi <memxor@gmail.com> wrote:
>
> On Wed, 19 Mar 2025 at 14:37, Kumar Kartikeya Dwivedi <memxor@gmail.com> wrote:
> >
> > On Wed, 19 Mar 2025 at 03:47, Alexei Starovoitov
> > <alexei.starovoitov@gmail.com> wrote:
> > >
> > > On Tue, Mar 18, 2025 at 7:33 PM Stephen Rothwell <sfr@canb.auug.org.au> 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@gmail.com/
> > >
> > > >
> > > > 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.
>

Can confirm now that this fixes it, I just did a build with GCC 14
where Uros's __percpu checks kick in.

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

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

[Alexei Starovoitov]

On Wed, Mar 19, 2025 at 7:36 AM Kumar Kartikeya Dwivedi
<memxor@gmail.com> wrote:
>
> > >
> > > 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.
> >
>
> Can confirm now that this fixes it, I just did a build with GCC 14
> where Uros's __percpu checks kick in.

Great. Thanks for checking and quick fix.

btw clang supports it with __attribute__((address_space(256))),
so CC_IS_GCC probably should be relaxed.

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

[Alexei Starovoitov]

On Wed, Mar 19, 2025 at 7:55 AM Alexei Starovoitov
<alexei.starovoitov@gmail.com> wrote:
>
> On Wed, Mar 19, 2025 at 7:36 AM Kumar Kartikeya Dwivedi
> <memxor@gmail.com> wrote:
> >
> > > >
> > > > 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.
> > >
> >
> > Can confirm now that this fixes it, I just did a build with GCC 14
> > where Uros's __percpu checks kick in.
>
> Great. Thanks for checking and quick fix.
>
> btw clang supports it with __attribute__((address_space(256))),
> so CC_IS_GCC probably should be relaxed.

Stephen,

bpf-next/for-next is force pushed with the fix.

Thank you for flagging it quickly! Appreciate it.

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

[Uros Bizjak]

On Wed, Mar 19, 2025 at 3:55 PM Alexei Starovoitov
<alexei.starovoitov@gmail.com> wrote:
>
> On Wed, Mar 19, 2025 at 7:36 AM Kumar Kartikeya Dwivedi
> <memxor@gmail.com> wrote:
> >
> > > >
> > > > 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.
> > >
> >
> > Can confirm now that this fixes it, I just did a build with GCC 14
> > where Uros's __percpu checks kick in.
>
> Great. Thanks for checking and quick fix.
>
> btw clang supports it with __attribute__((address_space(256))),
> so CC_IS_GCC probably should be relaxed.

https://github.com/llvm/llvm-project/issues/93449

needs to be fixed first. Also, the feature has to be thoroughly tested
(preferably by someone having a deep knowledge of clang) before it is
enabled by default.

Thanks,
Uros.

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

[Alexei Starovoitov]

On Wed, Mar 19, 2025 at 9:06 AM Uros Bizjak <ubizjak@gmail.com> wrote:
>
> On Wed, Mar 19, 2025 at 3:55 PM Alexei Starovoitov
> <alexei.starovoitov@gmail.com> wrote:
> >
> > On Wed, Mar 19, 2025 at 7:36 AM Kumar Kartikeya Dwivedi
> > <memxor@gmail.com> wrote:
> > >
> > > > >
> > > > > 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.
> > > >
> > >
> > > Can confirm now that this fixes it, I just did a build with GCC 14
> > > where Uros's __percpu checks kick in.
> >
> > Great. Thanks for checking and quick fix.
> >
> > btw clang supports it with __attribute__((address_space(256))),
> > so CC_IS_GCC probably should be relaxed.
>
> https://github.com/llvm/llvm-project/issues/93449
>
> needs to be fixed first. Also, the feature has to be thoroughly tested
> (preferably by someone having a deep knowledge of clang) before it is
> enabled by default.

clang error makes sense to me.
What does it even mean to do addr space cast from percpu to normal address:

__typeof__(int __seg_gs) const_pcpu_hot;
void *__attribute____UNIQUE_ID___addressable_const_pcpu_hot612 =
    (void *)(long)&const_pcpu_hot;

I'm curious what kind of code gcc generates.

In bpf backend we have the concept of address spaces and there are explicit
instructions generated to convert from one addr space to another.

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

[Uros Bizjak]

On Wed, Mar 19, 2025 at 7:56 PM Alexei Starovoitov
<alexei.starovoitov@gmail.com> wrote:
>
> On Wed, Mar 19, 2025 at 9:06 AM Uros Bizjak <ubizjak@gmail.com> wrote:
> >
> > On Wed, Mar 19, 2025 at 3:55 PM Alexei Starovoitov
> > <alexei.starovoitov@gmail.com> wrote:
> > >
> > > On Wed, Mar 19, 2025 at 7:36 AM Kumar Kartikeya Dwivedi
> > > <memxor@gmail.com> wrote:
> > > >
> > > > > >
> > > > > > 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.
> > > > >
> > > >
> > > > Can confirm now that this fixes it, I just did a build with GCC 14
> > > > where Uros's __percpu checks kick in.
> > >
> > > Great. Thanks for checking and quick fix.
> > >
> > > btw clang supports it with __attribute__((address_space(256))),
> > > so CC_IS_GCC probably should be relaxed.
> >
> > https://github.com/llvm/llvm-project/issues/93449
> >
> > needs to be fixed first. Also, the feature has to be thoroughly tested
> > (preferably by someone having a deep knowledge of clang) before it is
> > enabled by default.
>
> clang error makes sense to me.

It is not an error, but an internal compiler error. This should never happen.

> What does it even mean to do addr space cast from percpu to normal address:
>
> __typeof__(int __seg_gs) const_pcpu_hot;
> void *__attribute____UNIQUE_ID___addressable_const_pcpu_hot612 =
>     (void *)(long)&const_pcpu_hot;

Please see [1] for an explanation.

[1] https://gcc.gnu.org/onlinedocs/gcc/Named-Address-Spaces.html#x86-Named-Address-Spaces

Uros.

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

[Alexei Starovoitov]

On Wed, Mar 19, 2025 at 12:44 PM Uros Bizjak <ubizjak@gmail.com> wrote:
>
> On Wed, Mar 19, 2025 at 7:56 PM Alexei Starovoitov
> <alexei.starovoitov@gmail.com> wrote:
> >
> > On Wed, Mar 19, 2025 at 9:06 AM Uros Bizjak <ubizjak@gmail.com> wrote:
> > >
> > > On Wed, Mar 19, 2025 at 3:55 PM Alexei Starovoitov
> > > <alexei.starovoitov@gmail.com> wrote:
> > > >
> > > > On Wed, Mar 19, 2025 at 7:36 AM Kumar Kartikeya Dwivedi
> > > > <memxor@gmail.com> wrote:
> > > > >
> > > > > > >
> > > > > > > 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.
> > > > > >
> > > > >
> > > > > Can confirm now that this fixes it, I just did a build with GCC 14
> > > > > where Uros's __percpu checks kick in.
> > > >
> > > > Great. Thanks for checking and quick fix.
> > > >
> > > > btw clang supports it with __attribute__((address_space(256))),
> > > > so CC_IS_GCC probably should be relaxed.
> > >
> > > https://github.com/llvm/llvm-project/issues/93449
> > >
> > > needs to be fixed first. Also, the feature has to be thoroughly tested
> > > (preferably by someone having a deep knowledge of clang) before it is
> > > enabled by default.
> >
> > clang error makes sense to me.
>
> It is not an error, but an internal compiler error. This should never happen.

Not quite. llvm backends don't have a good way to explain the error,
but this is invalid condition.
Arguably llvm should do a better job in such cases instead of
printing stack trace.

>
> > What does it even mean to do addr space cast from percpu to normal address:
> >
> > __typeof__(int __seg_gs) const_pcpu_hot;
> > void *__attribute____UNIQUE_ID___addressable_const_pcpu_hot612 =
> >     (void *)(long)&const_pcpu_hot;
>
> Please see [1] for an explanation.
>
> [1] https://gcc.gnu.org/onlinedocs/gcc/Named-Address-Spaces.html#x86-Named-Address-Spaces

You didn't answer my question.

As suspected, gcc is producing garbage code.

See:
https://godbolt.org/z/ozozYY3nv

For
void *ptr = (void *)(long)&pcpu_hot;

gcc emits
.quad pcpu_hot
which is nonsensical, while clang refuses to produce garbage
and dumps stack.

Sadly, both compilers produce garbage for ret_addr()

and both compilers produce correct code for ret_value().
At least something.

Uros,
your percpu code is broken.
you shouldn't rely on gcc producing garbage.
Sooner or later gcc will start erroring on it just as clang.

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

[Uros Bizjak]

On Thu, Mar 20, 2025 at 12:17 AM Alexei Starovoitov
<alexei.starovoitov@gmail.com> wrote:
>
> On Wed, Mar 19, 2025 at 12:44 PM Uros Bizjak <ubizjak@gmail.com> wrote:
> >
> > On Wed, Mar 19, 2025 at 7:56 PM Alexei Starovoitov
> > <alexei.starovoitov@gmail.com> wrote:
> > >
> > > On Wed, Mar 19, 2025 at 9:06 AM Uros Bizjak <ubizjak@gmail.com> wrote:
> > > >
> > > > On Wed, Mar 19, 2025 at 3:55 PM Alexei Starovoitov
> > > > <alexei.starovoitov@gmail.com> wrote:
> > > > >
> > > > > On Wed, Mar 19, 2025 at 7:36 AM Kumar Kartikeya Dwivedi
> > > > > <memxor@gmail.com> wrote:
> > > > > >
> > > > > > > >
> > > > > > > > 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.
> > > > > > >
> > > > > >
> > > > > > Can confirm now that this fixes it, I just did a build with GCC 14
> > > > > > where Uros's __percpu checks kick in.
> > > > >
> > > > > Great. Thanks for checking and quick fix.
> > > > >
> > > > > btw clang supports it with __attribute__((address_space(256))),
> > > > > so CC_IS_GCC probably should be relaxed.
> > > >
> > > > https://github.com/llvm/llvm-project/issues/93449
> > > >
> > > > needs to be fixed first. Also, the feature has to be thoroughly tested
> > > > (preferably by someone having a deep knowledge of clang) before it is
> > > > enabled by default.
> > >
> > > clang error makes sense to me.
> >
> > It is not an error, but an internal compiler error. This should never happen.
>
> Not quite. llvm backends don't have a good way to explain the error,
> but this is invalid condition.
> Arguably llvm should do a better job in such cases instead of
> printing stack trace.
>
> >
> > > What does it even mean to do addr space cast from percpu to normal address:
> > >
> > > __typeof__(int __seg_gs) const_pcpu_hot;
> > > void *__attribute____UNIQUE_ID___addressable_const_pcpu_hot612 =
> > >     (void *)(long)&const_pcpu_hot;
> >
> > Please see [1] for an explanation.
> >
> > [1] https://gcc.gnu.org/onlinedocs/gcc/Named-Address-Spaces.html#x86-Named-Address-Spaces
>
> You didn't answer my question.

Actually, the above link explains and documents the issue:

"... these address spaces are not considered to be subspaces of the
generic (flat) address space. This means that explicit casts are
required to convert pointers between these address spaces and the
generic address space. In practice the application should cast to
uintptr_t and apply the segment base offset that it installed
previously."

IOW, for __seg_gs address space, there exists no (known) offset that
would define it as a subspace of the generic space. It is gs: prefix
that results in segment override that "switches" to __seg_gs address
space. So, to convert the pointer from __seg_gs to (nonsensical!)
generic address space, GCC allows explicit (void *)(uintptr_t) cast
that in effect just strips gs: prefix from the address. You can then
use the pointer as a pointer to a generic space, but you can't use it
to dereference data from __seg_gs address space - this would be
nonsensical, so (__seg_gs void *)(uintptr_t) cast is needed to convert
pointer back to __seg_gs AS.

> As suspected, gcc is producing garbage code.

Nope, this is expected and well documented behavior.

> See:
> https://godbolt.org/z/ozozYY3nv
>
> For
> void *ptr = (void *)(long)&pcpu_hot;
>
> gcc emits
> .quad pcpu_hot
> which is nonsensical, while clang refuses to produce garbage
> and dumps stack.
>
> Sadly, both compilers produce garbage for ret_addr()

No, they are correct. The pointer is explicitly cast to generic
address space and this is what you get.

> and both compilers produce correct code for ret_value().
> At least something.
>
> Uros,
> your percpu code is broken.
> you shouldn't rely on gcc producing garbage.
> Sooner or later gcc will start erroring on it just as clang.

It won't. It is well documented behavior, as documented in [1].
Regarding linux code, you "should not" pass a pointer to generic
address space to dereference percpu data. Currently,
__verify_percpu_ptr() only triggers a warning when sparse checking is
used, but my patchset will now enforce this as a compile-time error
(this was a much sought feature, and it was possible to implement only
recently by using the newly introduced typeof_unqual() operator). Rest
assured, before enabling this feature in linux, plenty of people
unsuccessfully tried to poke a hole in this functionality and long
threads are archived where address space functionality was discussed
to death. ;)

BTW: You can use:

--cut here--
diff --git a/arch/x86/include/asm/percpu.h b/arch/x86/include/asm/percpu.h
index 474d648bca9a..e6a7525c9db9 100644
--- a/arch/x86/include/asm/percpu.h
+++ b/arch/x86/include/asm/percpu.h
@@ -105,6 +105,10 @@
 # define __my_cpu_type(var)    typeof(var) __percpu_seg_override
 # define __my_cpu_ptr(ptr)    (__my_cpu_type(*(ptr))*)(__force uintptr_t)(ptr)
 # define __my_cpu_var(var)    (*__my_cpu_ptr(&(var)))
+
+# if __has_attribute(address_space) && defined(USE_TYPEOF_UNQUAL)
+#  define __percpu_qual        __attribute__((address_space(3)))
+# endif
 #endif

 #define __percpu_arg(x)        __percpu_prefix "%" #x
--cut here--

to also see clang's address space checks in action on x86 even without
working __seg_gs support (You will need to disable
Wduplicate-decl-specifier warning).

HTH,
Uros.

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

[Alexei Starovoitov]

On Thu, Mar 20, 2025 at 12:49 AM Uros Bizjak <ubizjak@gmail.com> wrote:
>
> On Thu, Mar 20, 2025 at 12:17 AM Alexei Starovoitov
> <alexei.starovoitov@gmail.com> wrote:
> >
> > On Wed, Mar 19, 2025 at 12:44 PM Uros Bizjak <ubizjak@gmail.com> wrote:
> > >
> > > On Wed, Mar 19, 2025 at 7:56 PM Alexei Starovoitov
> > > <alexei.starovoitov@gmail.com> wrote:
> > > >
> > > > On Wed, Mar 19, 2025 at 9:06 AM Uros Bizjak <ubizjak@gmail.com> wrote:
> > > > >
> > > > > On Wed, Mar 19, 2025 at 3:55 PM Alexei Starovoitov
> > > > > <alexei.starovoitov@gmail.com> wrote:
> > > > > >
> > > > > > On Wed, Mar 19, 2025 at 7:36 AM Kumar Kartikeya Dwivedi
> > > > > > <memxor@gmail.com> wrote:
> > > > > > >
> > > > > > > > >
> > > > > > > > > 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.
> > > > > > > >
> > > > > > >
> > > > > > > Can confirm now that this fixes it, I just did a build with GCC 14
> > > > > > > where Uros's __percpu checks kick in.
> > > > > >
> > > > > > Great. Thanks for checking and quick fix.
> > > > > >
> > > > > > btw clang supports it with __attribute__((address_space(256))),
> > > > > > so CC_IS_GCC probably should be relaxed.
> > > > >
> > > > > https://github.com/llvm/llvm-project/issues/93449
> > > > >
> > > > > needs to be fixed first. Also, the feature has to be thoroughly tested
> > > > > (preferably by someone having a deep knowledge of clang) before it is
> > > > > enabled by default.
> > > >
> > > > clang error makes sense to me.
> > >
> > > It is not an error, but an internal compiler error. This should never happen.
> >
> > Not quite. llvm backends don't have a good way to explain the error,
> > but this is invalid condition.
> > Arguably llvm should do a better job in such cases instead of
> > printing stack trace.
> >
> > >
> > > > What does it even mean to do addr space cast from percpu to normal address:
> > > >
> > > > __typeof__(int __seg_gs) const_pcpu_hot;
> > > > void *__attribute____UNIQUE_ID___addressable_const_pcpu_hot612 =
> > > >     (void *)(long)&const_pcpu_hot;
> > >
> > > Please see [1] for an explanation.
> > >
> > > [1] https://gcc.gnu.org/onlinedocs/gcc/Named-Address-Spaces.html#x86-Named-Address-Spaces
> >
> > You didn't answer my question.
>
> Actually, the above link explains and documents the issue:
>
> "... these address spaces are not considered to be subspaces of the
> generic (flat) address space. This means that explicit casts are
> required to convert pointers between these address spaces and the
> generic address space. In practice the application should cast to
> uintptr_t and apply the segment base offset that it installed
> previously."
>
> IOW, for __seg_gs address space, there exists no (known) offset that
> would define it as a subspace of the generic space. It is gs: prefix
> that results in segment override that "switches" to __seg_gs address
> space. So, to convert the pointer from __seg_gs to (nonsensical!)
> generic address space, GCC allows explicit (void *)(uintptr_t) cast
> that in effect just strips gs: prefix from the address. You can then
> use the pointer as a pointer to a generic space, but you can't use it
> to dereference data from __seg_gs address space - this would be
> nonsensical, so (__seg_gs void *)(uintptr_t) cast is needed to convert
> pointer back to __seg_gs AS.

tbh, I don't see how the above doc sentence means "just strip gs:".
But ok, if that's what gcc folks clarified as true intent and it's
not going to change.
btw both compilers disallow automatic variables with address space
qualifier and that makes sense, but if "just strip gs:" would be
the rule then auto var with gs should have meant "just strip" too.
Weird.

> > As suspected, gcc is producing garbage code.
>
> Nope, this is expected and well documented behavior.
>
> > See:
> > https://godbolt.org/z/ozozYY3nv
> >
> > For
> > void *ptr = (void *)(long)&pcpu_hot;
> >
> > gcc emits
> > .quad pcpu_hot
> > which is nonsensical, while clang refuses to produce garbage
> > and dumps stack.
> >
> > Sadly, both compilers produce garbage for ret_addr()
>
> No, they are correct. The pointer is explicitly cast to generic
> address space and this is what you get.
>
> > and both compilers produce correct code for ret_value().
> > At least something.
> >
> > Uros,
> > your percpu code is broken.
> > you shouldn't rely on gcc producing garbage.
> > Sooner or later gcc will start erroring on it just as clang.
>
> It won't. It is well documented behavior, as documented in [1].
> Regarding linux code, you "should not" pass a pointer to generic
> address space to dereference percpu data. Currently,
> __verify_percpu_ptr() only triggers a warning when sparse checking is
> used, but my patchset will now enforce this as a compile-time error
> (this was a much sought feature, and it was possible to implement only
> recently by using the newly introduced typeof_unqual() operator).

That value proposition of the patch is clear. It's a good check,
no doubt. My point that compilers could have done it just fine
without using this "just strip gs:" rule for global percpu variables.
I suspect it should be possible to craft the macro
without assigning (void *)(long)&pcpu_hot into global var.
And both compilers would have worked.

> Rest
> assured, before enabling this feature in linux, plenty of people
> unsuccessfully tried to poke a hole in this functionality and long
> threads are archived where address space functionality was discussed
> to death. ;)
>
> BTW: You can use:
>
> --cut here--
> diff --git a/arch/x86/include/asm/percpu.h b/arch/x86/include/asm/percpu.h
> index 474d648bca9a..e6a7525c9db9 100644
> --- a/arch/x86/include/asm/percpu.h
> +++ b/arch/x86/include/asm/percpu.h
> @@ -105,6 +105,10 @@
>  # define __my_cpu_type(var)    typeof(var) __percpu_seg_override
>  # define __my_cpu_ptr(ptr)    (__my_cpu_type(*(ptr))*)(__force uintptr_t)(ptr)
>  # define __my_cpu_var(var)    (*__my_cpu_ptr(&(var)))
> +
> +# if __has_attribute(address_space) && defined(USE_TYPEOF_UNQUAL)
> +#  define __percpu_qual        __attribute__((address_space(3)))

I see, so for undefined addr spaces clang x86 just ignores it.
Weird. But ok.

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

[Uros Bizjak]

On Fri, Mar 21, 2025 at 12:18 AM Alexei Starovoitov
<alexei.starovoitov@gmail.com> wrote:

> > BTW: You can use:
> >
> > --cut here--
> > diff --git a/arch/x86/include/asm/percpu.h b/arch/x86/include/asm/percpu.h
> > index 474d648bca9a..e6a7525c9db9 100644
> > --- a/arch/x86/include/asm/percpu.h
> > +++ b/arch/x86/include/asm/percpu.h
> > @@ -105,6 +105,10 @@
> >  # define __my_cpu_type(var)    typeof(var) __percpu_seg_override
> >  # define __my_cpu_ptr(ptr)    (__my_cpu_type(*(ptr))*)(__force uintptr_t)(ptr)
> >  # define __my_cpu_var(var)    (*__my_cpu_ptr(&(var)))
> > +
> > +# if __has_attribute(address_space) && defined(USE_TYPEOF_UNQUAL)
> > +#  define __percpu_qual        __attribute__((address_space(3)))
>
> I see, so for undefined addr spaces clang x86 just ignores it.
> Weird. But ok.

It ignores undefined addr spaces in the sense that it does nothing
with it. It has no effect on the access to variables in this addr
space. OTOH, the compiler still applies address space checks. I plan
to propose a (RFC?) patch after rc1, once the main part is applied to
the mainline, that enables percpu checks also for clang. It is in
effect just the above couple of lines.

Uros.