Subject: linux-next: manual merge of the bpf-next tree with the net tree

From: Stephen Rothwell <[email-masked]>
Date: Mon, 29 Apr 2024 11:49:39 +1000

Hi all,

Today's linux-next merge of the bpf-next tree got conflicts in:

  include/linux/filter.h
  kernel/bpf/core.c

between commit:

  66e13b615a0c ("bpf: verifier: prevent userspace memory access")

from the net tree and commit:

  d503a04f8bc0 ("bpf: Add support for certain atomics in bpf_arena to x86 JIT")

from the bpf-next tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc include/linux/filter.h
index 42dbceb04ca6,7a27f19bf44d..000000000000
--- a/include/linux/filter.h
+++ b/include/linux/filter.h
@@@ -975,7 -1000,7 +1000,8 @@@ bool bpf_jit_supports_far_kfunc_call(vo
  bool bpf_jit_supports_exceptions(void);
  bool bpf_jit_supports_ptr_xchg(void);
  bool bpf_jit_supports_arena(void);
 +u64 bpf_arch_uaddress_limit(void);
+ bool bpf_jit_supports_insn(struct bpf_insn *insn, bool in_arena);
  void arch_bpf_stack_walk(bool (*consume_fn)(void *cookie, u64 ip, u64 sp, u64 bp), void *cookie);
  bool bpf_helper_changes_pkt_data(void *func);
  
diff --cc kernel/bpf/core.c
index a04695ca82b9,95c7fd093e55..000000000000
--- a/kernel/bpf/core.c
+++ b/kernel/bpf/core.c
@@@ -2958,15 -2965,11 +2965,20 @@@ bool __weak bpf_jit_supports_arena(void
  	return false;
  }
  
 +u64 __weak bpf_arch_uaddress_limit(void)
 +{
 +#if defined(CONFIG_64BIT) && defined(CONFIG_ARCH_HAS_NON_OVERLAPPING_ADDRESS_SPACE)
 +	return TASK_SIZE;
 +#else
 +	return 0;
 +#endif
 +}
 +
+ bool __weak bpf_jit_supports_insn(struct bpf_insn *insn, bool in_arena)
+ {
+ 	return false;
+ }
+ 
  /* Return TRUE if the JIT backend satisfies the following two conditions:
   * 1) JIT backend supports atomic_xchg() on pointer-sized words.
   * 2) Under the specific arch, the implementation of xchg() is the same