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

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

[Stephen Rothwell]

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

Hi all,

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

  tools/testing/selftests/bpf/DENYLIST.s390x

between commit:

  27e23836ce22 ("selftests/bpf: Add lru_bug to s390x deny list")

from the bpf tree and commits:

  b979f005d9b1 ("selftest/bpf: Add setget_sockopt to DENYLIST.s390x")
  092e67772728 ("selftests/bpf: Add cb_refs test to s390x deny list")

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 tools/testing/selftests/bpf/DENYLIST.s390x
index 5cadfbdadf36,37bafcbf952a..000000000000
--- a/tools/testing/selftests/bpf/DENYLIST.s390x
+++ b/tools/testing/selftests/bpf/DENYLIST.s390x
@@@ -65,4 -65,5 +65,6 @@@ send_signa
  select_reuseport                         # intermittently fails on new s390x setup
  xdp_synproxy                             # JIT does not support calling kernel function                                (kfunc)
  unpriv_bpf_disabled                      # fentry
 +lru_bug                                  # prog 'printk': failed to auto-attach: -524
+ setget_sockopt                           # attach unexpected error: -524                                               (trampoline)
+ cb_refs                                  # expected error message unexpected error: -524                               (trampoline)

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

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

[Stephen Rothwell]

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

Hi all,

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

  tools/testing/selftests/bpf/progs/verifier_iterating_callbacks.c

between commit:

  5c2bc5e2f81d ("selftests/bpf: test case for callback_depth states pruning logic")

from the bpf tree and commit:

  0c8bbf990bdd ("selftests/bpf: Test may_goto")

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 tools/testing/selftests/bpf/progs/verifier_iterating_callbacks.c
index a955a6358206,04cdbce4652f..000000000000
--- a/tools/testing/selftests/bpf/progs/verifier_iterating_callbacks.c
+++ b/tools/testing/selftests/bpf/progs/verifier_iterating_callbacks.c
@@@ -239,74 -237,103 +237,173 @@@ int bpf_loop_iter_limit_nested(void *un
  	return 1000 * a + b + c;
  }
  
 +struct iter_limit_bug_ctx {
 +	__u64 a;
 +	__u64 b;
 +	__u64 c;
 +};
 +
 +static __naked void iter_limit_bug_cb(void)
 +{
 +	/* This is the same as C code below, but written
 +	 * in assembly to control which branches are fall-through.
 +	 *
 +	 *   switch (bpf_get_prandom_u32()) {
 +	 *   case 1:  ctx->a = 42; break;
 +	 *   case 2:  ctx->b = 42; break;
 +	 *   default: ctx->c = 42; break;
 +	 *   }
 +	 */
 +	asm volatile (
 +	"r9 = r2;"
 +	"call %[bpf_get_prandom_u32];"
 +	"r1 = r0;"
 +	"r2 = 42;"
 +	"r0 = 0;"
 +	"if r1 == 0x1 goto 1f;"
 +	"if r1 == 0x2 goto 2f;"
 +	"*(u64 *)(r9 + 16) = r2;"
 +	"exit;"
 +	"1: *(u64 *)(r9 + 0) = r2;"
 +	"exit;"
 +	"2: *(u64 *)(r9 + 8) = r2;"
 +	"exit;"
 +	:
 +	: __imm(bpf_get_prandom_u32)
 +	: __clobber_all
 +	);
 +}
 +
 +SEC("tc")
 +__failure
 +__flag(BPF_F_TEST_STATE_FREQ)
 +int iter_limit_bug(struct __sk_buff *skb)
 +{
 +	struct iter_limit_bug_ctx ctx = { 7, 7, 7 };
 +
 +	bpf_loop(2, iter_limit_bug_cb, &ctx, 0);
 +
 +	/* This is the same as C code below,
 +	 * written in assembly to guarantee checks order.
 +	 *
 +	 *   if (ctx.a == 42 && ctx.b == 42 && ctx.c == 7)
 +	 *     asm volatile("r1 /= 0;":::"r1");
 +	 */
 +	asm volatile (
 +	"r1 = *(u64 *)%[ctx_a];"
 +	"if r1 != 42 goto 1f;"
 +	"r1 = *(u64 *)%[ctx_b];"
 +	"if r1 != 42 goto 1f;"
 +	"r1 = *(u64 *)%[ctx_c];"
 +	"if r1 != 7 goto 1f;"
 +	"r1 /= 0;"
 +	"1:"
 +	:
 +	: [ctx_a]"m"(ctx.a),
 +	  [ctx_b]"m"(ctx.b),
 +	  [ctx_c]"m"(ctx.c)
 +	: "r1"
 +	);
 +	return 0;
 +}
 +
+ #define ARR_SZ 1000000
+ int zero;
+ char arr[ARR_SZ];
+ 
+ SEC("socket")
+ __success __retval(0xd495cdc0)
+ int cond_break1(const void *ctx)
+ {
+ 	unsigned long i;
+ 	unsigned int sum = 0;
+ 
+ 	for (i = zero; i < ARR_SZ; cond_break, i++)
+ 		sum += i;
+ 	for (i = zero; i < ARR_SZ; i++) {
+ 		barrier_var(i);
+ 		sum += i + arr[i];
+ 		cond_break;
+ 	}
+ 
+ 	return sum;
+ }
+ 
+ SEC("socket")
+ __success __retval(999000000)
+ int cond_break2(const void *ctx)
+ {
+ 	int i, j;
+ 	int sum = 0;
+ 
+ 	for (i = zero; i < 1000; cond_break, i++)
+ 		for (j = zero; j < 1000; j++) {
+ 			sum += i + j;
+ 			cond_break;
+ 		}
+ 
+ 	return sum;
+ }
+ 
+ static __noinline int loop(void)
+ {
+ 	int i, sum = 0;
+ 
+ 	for (i = zero; i <= 1000000; i++, cond_break)
+ 		sum += i;
+ 
+ 	return sum;
+ }
+ 
+ SEC("socket")
+ __success __retval(0x6a5a2920)
+ int cond_break3(const void *ctx)
+ {
+ 	return loop();
+ }
+ 
+ SEC("socket")
+ __success __retval(1)
+ int cond_break4(const void *ctx)
+ {
+ 	int cnt = zero;
+ 
+ 	for (;;) {
+ 		/* should eventually break out of the loop */
+ 		cond_break;
+ 		cnt++;
+ 	}
+ 	/* if we looped a bit, it's a success */
+ 	return cnt > 1 ? 1 : 0;
+ }
+ 
+ static __noinline int static_subprog(void)
+ {
+ 	int cnt = zero;
+ 
+ 	for (;;) {
+ 		cond_break;
+ 		cnt++;
+ 	}
+ 
+ 	return cnt;
+ }
+ 
+ SEC("socket")
+ __success __retval(1)
+ int cond_break5(const void *ctx)
+ {
+ 	int cnt1 = zero, cnt2;
+ 
+ 	for (;;) {
+ 		cond_break;
+ 		cnt1++;
+ 	}
+ 
+ 	cnt2 = static_subprog();
+ 
+ 	/* main and subprog have to loop a bit */
+ 	return cnt1 > 1 && cnt2 > 1 ? 1 : 0;
+ }
+ 
  char _license[] SEC("license") = "GPL";

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

Re: linux-next: manual merge of the bpf-next tree with the bpf tree

[Bagas Sanjaya]

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

On Tue, Mar 07, 2023 at 09:58:12AM +1100, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the bpf-next tree got a conflict in:
> 
>   Documentation/bpf/bpf_devel_QA.rst
> 
> between commit:
> 
>   b7abcd9c656b ("bpf, doc: Link to submitting-patches.rst for general patch submission info")
> 
> from the bpf tree and commit:
> 
>   d56b0c461d19 ("bpf, docs: Fix link to netdev-FAQ target")
> 
> 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 Documentation/bpf/bpf_devel_QA.rst
> index b421d94dc9f2,5f5f9ccc3862..000000000000
> --- a/Documentation/bpf/bpf_devel_QA.rst
> +++ b/Documentation/bpf/bpf_devel_QA.rst
> @@@ -684,8 -684,12 +684,8 @@@ when
>   
>   
>   .. Links
> - .. _netdev-FAQ: Documentation/process/maintainer-netdev.rst
>  -.. _Documentation/process/: https://www.kernel.org/doc/html/latest/process/
> + .. _netdev-FAQ: https://www.kernel.org/doc/html/latest/process/maintainer-netdev.html
>   .. _selftests:
>      https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/tools/testing/selftests/bpf/
>  -.. _Documentation/dev-tools/kselftest.rst:
>  -   https://www.kernel.org/doc/html/latest/dev-tools/kselftest.html
>  -.. _Documentation/bpf/btf.rst: btf.rst
>   
>   Happy BPF hacking!

I think the correct solution is to instead use internal link to netdev FAQ,
to be consistent with my change in bpf tree:

---- >8 ----
diff --git a/Documentation/bpf/bpf_devel_QA.rst b/Documentation/bpf/bpf_devel_QA.rst
index 5f5f9ccc3862b4..e523991da9e0ce 100644
--- a/Documentation/bpf/bpf_devel_QA.rst
+++ b/Documentation/bpf/bpf_devel_QA.rst
@@ -128,7 +128,7 @@ into the bpf-next tree will make their way into net-next tree. net and
 net-next are both run by David S. Miller. From there, they will go
 into the kernel mainline tree run by Linus Torvalds. To read up on the
 process of net and net-next being merged into the mainline tree, see
-the `netdev-FAQ`_.
+the :doc:`netdev-FAQ </process/maintainer-netdev>`.
 
 
 
@@ -147,7 +147,8 @@ request)::
 Q: How do I indicate which tree (bpf vs. bpf-next) my patch should be applied to?
 ---------------------------------------------------------------------------------
 
-A: The process is the very same as described in the `netdev-FAQ`_,
+A: The process is the very same as described in the
+:doc:`netdev-FAQ </process/maintainer-netdev>`,
 so please read up on it. The subject line must indicate whether the
 patch is a fix or rather "next-like" content in order to let the
 maintainers know whether it is targeted at bpf or bpf-next.
@@ -206,8 +207,8 @@ ii) run extensive BPF test suite and
 Once the BPF pull request was accepted by David S. Miller, then
 the patches end up in net or net-next tree, respectively, and
 make their way from there further into mainline. Again, see the
-`netdev-FAQ`_ for additional information e.g. on how often they are
-merged to mainline.
+:doc:`netdev-FAQ </process/maintainer-netdev>` for additional
+information e.g. on how often they are merged to mainline.
 
 Q: How long do I need to wait for feedback on my BPF patches?
 -------------------------------------------------------------
@@ -230,7 +231,8 @@ Q: Are patches applied to bpf-next when the merge window is open?
 -----------------------------------------------------------------
 A: For the time when the merge window is open, bpf-next will not be
 processed. This is roughly analogous to net-next patch processing,
-so feel free to read up on the `netdev-FAQ`_ about further details.
+so feel free to read up on the
+:doc:`netdev-FAQ </process/maintainer-netdev>` about further details.
 
 During those two weeks of merge window, we might ask you to resend
 your patch series once bpf-next is open again. Once Linus released
@@ -394,7 +396,7 @@ netdev kernel mailing list in Cc and ask for the fix to be queued up:
   netdev@vger.kernel.org
 
 The process in general is the same as on netdev itself, see also the
-`netdev-FAQ`_.
+:doc:`netdev-FAQ </process/maintainer-netdev>`.
 
 Q: Do you also backport to kernels not currently maintained as stable?
 ----------------------------------------------------------------------
@@ -410,7 +412,7 @@ Q: The BPF patch I am about to submit needs to go to stable as well
 What should I do?
 
 A: The same rules apply as with netdev patch submissions in general, see
-the `netdev-FAQ`_.
+the :doc:`netdev-FAQ </process/maintainer-netdev>`.
 
 Never add "``Cc: stable@vger.kernel.org``" to the patch description, but
 ask the BPF maintainers to queue the patches instead. This can be done
@@ -685,7 +687,6 @@ when:
 
 .. Links
 .. _Documentation/process/: https://www.kernel.org/doc/html/latest/process/
-.. _netdev-FAQ: https://www.kernel.org/doc/html/latest/process/maintainer-netdev.html
 .. _selftests:
    https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/tools/testing/selftests/bpf/
 .. _Documentation/dev-tools/kselftest.rst:


Thanks.

-- 
An old man doll... just what I always wanted! - Clara

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

Re: linux-next: manual merge of the bpf-next tree with the bpf tree

[Stephen Rothwell]

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

Hi all,

On Tue, 7 Mar 2023 09:58:12 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> 
> Today's linux-next merge of the bpf-next tree got a conflict in:
> 
>   Documentation/bpf/bpf_devel_QA.rst
> 
> between commit:
> 
>   b7abcd9c656b ("bpf, doc: Link to submitting-patches.rst for general patch submission info")
> 
> from the bpf tree and commit:
> 
>   d56b0c461d19 ("bpf, docs: Fix link to netdev-FAQ target")
> 
> 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 Documentation/bpf/bpf_devel_QA.rst
> index b421d94dc9f2,5f5f9ccc3862..000000000000
> --- a/Documentation/bpf/bpf_devel_QA.rst
> +++ b/Documentation/bpf/bpf_devel_QA.rst
> @@@ -684,8 -684,12 +684,8 @@@ when
>   
>   
>   .. Links
> - .. _netdev-FAQ: Documentation/process/maintainer-netdev.rst
>  -.. _Documentation/process/: https://www.kernel.org/doc/html/latest/process/
> + .. _netdev-FAQ: https://www.kernel.org/doc/html/latest/process/maintainer-netdev.html
>   .. _selftests:
>      https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/tools/testing/selftests/bpf/
>  -.. _Documentation/dev-tools/kselftest.rst:
>  -   https://www.kernel.org/doc/html/latest/dev-tools/kselftest.html
>  -.. _Documentation/bpf/btf.rst: btf.rst
>   
>   Happy BPF hacking!

This is now a conflict between the net-next tree and Linus' tree.

-- 
Cheers,
Stephen Rothwell

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

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

[Stephen Rothwell]

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

Hi all,

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

  Documentation/bpf/bpf_devel_QA.rst

between commit:

  b7abcd9c656b ("bpf, doc: Link to submitting-patches.rst for general patch submission info")

from the bpf tree and commit:

  d56b0c461d19 ("bpf, docs: Fix link to netdev-FAQ target")

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 Documentation/bpf/bpf_devel_QA.rst
index b421d94dc9f2,5f5f9ccc3862..000000000000
--- a/Documentation/bpf/bpf_devel_QA.rst
+++ b/Documentation/bpf/bpf_devel_QA.rst
@@@ -684,8 -684,12 +684,8 @@@ when
  
  
  .. Links
- .. _netdev-FAQ: Documentation/process/maintainer-netdev.rst
 -.. _Documentation/process/: https://www.kernel.org/doc/html/latest/process/
+ .. _netdev-FAQ: https://www.kernel.org/doc/html/latest/process/maintainer-netdev.html
  .. _selftests:
     https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/tools/testing/selftests/bpf/
 -.. _Documentation/dev-tools/kselftest.rst:
 -   https://www.kernel.org/doc/html/latest/dev-tools/kselftest.html
 -.. _Documentation/bpf/btf.rst: btf.rst
  
  Happy BPF hacking!

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

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

[Stephen Rothwell]

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

Hi all,

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

  tools/lib/bpf/ringbuf.c

between commit:

  927cbb478adf ("libbpf: Handle size overflow for ringbuf mmap")

from the bpf tree and commit:

  b486d19a0ab0 ("libbpf: checkpatch: Fixed code alignments in ringbuf.c")

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 tools/lib/bpf/ringbuf.c
index 6af142953a94,51808c5f0014..000000000000
--- a/tools/lib/bpf/ringbuf.c
+++ b/tools/lib/bpf/ringbuf.c
@@@ -128,13 -128,9 +128,13 @@@ int ring_buffer__add(struct ring_buffe
  	/* Map read-only producer page and data pages. We map twice as big
  	 * data size to allow simple reading of samples that wrap around the
  	 * end of a ring buffer. See kernel implementation for details.
- 	 * */
+ 	 */
 -	tmp = mmap(NULL, rb->page_size + 2 * info.max_entries, PROT_READ,
 -		   MAP_SHARED, map_fd, rb->page_size);
 +	mmap_sz = rb->page_size + 2 * (__u64)info.max_entries;
 +	if (mmap_sz != (__u64)(size_t)mmap_sz) {
 +		pr_warn("ringbuf: ring buffer size (%u) is too big\n", info.max_entries);
 +		return libbpf_err(-E2BIG);
 +	}
 +	tmp = mmap(NULL, (size_t)mmap_sz, PROT_READ, MAP_SHARED, map_fd, rb->page_size);
  	if (tmp == MAP_FAILED) {
  		err = -errno;
  		ringbuf_unmap_ring(rb, r);

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

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

[Stephen Rothwell]

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

Hi all,

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

  tools/testing/selftests/bpf/DENYLIST.s390x

between commit:

  27e23836ce22 ("selftests/bpf: Add lru_bug to s390x deny list")

from the bpf tree and commit:

  88886309d2e8 ("selftests/bpf: add a selftest for cgroup hierarchical stats collection")

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 tools/testing/selftests/bpf/DENYLIST.s390x
index 5cadfbdadf36,736b65f61022..000000000000
--- a/tools/testing/selftests/bpf/DENYLIST.s390x
+++ b/tools/testing/selftests/bpf/DENYLIST.s390x
@@@ -65,4 -65,6 +65,7 @@@ send_signa
  select_reuseport                         # intermittently fails on new s390x setup
  xdp_synproxy                             # JIT does not support calling kernel function                                (kfunc)
  unpriv_bpf_disabled                      # fentry
 +lru_bug                                  # prog 'printk': failed to auto-attach: -524
+ setget_sockopt                           # attach unexpected error: -524                                               (trampoline)
+ cb_refs                                  # expected error message unexpected error: -524                               (trampoline)
+ cgroup_hierarchical_stats                # JIT does not support calling kernel function                                (kfunc)

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

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

[Stephen Rothwell]

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

Hi all,

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

  tools/testing/selftests/bpf/DENYLIST.s390x

between commit:

  27e23836ce22 ("selftests/bpf: Add lru_bug to s390x deny list")

from the bpf tree and commit:

  b979f005d9b1 ("selftest/bpf: Add setget_sockopt to DENYLIST.s390x")

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 tools/testing/selftests/bpf/DENYLIST.s390x
index 5cadfbdadf36,a708c3dcc154..000000000000
--- a/tools/testing/selftests/bpf/DENYLIST.s390x
+++ b/tools/testing/selftests/bpf/DENYLIST.s390x
@@@ -65,4 -65,4 +65,5 @@@ send_signa
  select_reuseport                         # intermittently fails on new s390x setup
  xdp_synproxy                             # JIT does not support calling kernel function                                (kfunc)
  unpriv_bpf_disabled                      # fentry
 +lru_bug                                  # prog 'printk': failed to auto-attach: -524
+ setget_sockopt                           # attach unexpected error: -524                                               (trampoline)

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

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

[Stephen Rothwell]

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

Hi all,

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

  kernel/bpf/btf.c

between commit:

  d9847eb8be3d ("bpf: Make CONFIG_DEBUG_INFO_BTF depend upon CONFIG_BPF_SYSCALL")

from the bpf tree and commit:

  29db4bea1d10 ("bpf: Prepare relo_core.c for kernel duty.")

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 kernel/bpf/btf.c
index 48cdf5b425a7,36a5cc0f53c6..000000000000
--- a/kernel/bpf/btf.c
+++ b/kernel/bpf/btf.c
@@@ -6405,4 -6418,382 +6409,384 @@@ bool bpf_check_mod_kfunc_call(struct kf
  DEFINE_KFUNC_BTF_ID_LIST(bpf_tcp_ca_kfunc_list);
  DEFINE_KFUNC_BTF_ID_LIST(prog_test_kfunc_list);
  
 +#endif
++
+ int bpf_core_types_are_compat(const struct btf *local_btf, __u32 local_id,
+ 			      const struct btf *targ_btf, __u32 targ_id)
+ {
+ 	return -EOPNOTSUPP;
+ }
+ 
+ static bool bpf_core_is_flavor_sep(const char *s)
+ {
+ 	/* check X___Y name pattern, where X and Y are not underscores */
+ 	return s[0] != '_' &&				      /* X */
+ 	       s[1] == '_' && s[2] == '_' && s[3] == '_' &&   /* ___ */
+ 	       s[4] != '_';				      /* Y */
+ }
+ 
+ size_t bpf_core_essential_name_len(const char *name)
+ {
+ 	size_t n = strlen(name);
+ 	int i;
+ 
+ 	for (i = n - 5; i >= 0; i--) {
+ 		if (bpf_core_is_flavor_sep(name + i))
+ 			return i + 1;
+ 	}
+ 	return n;
+ }
+ 
+ struct bpf_cand_cache {
+ 	const char *name;
+ 	u32 name_len;
+ 	u16 kind;
+ 	u16 cnt;
+ 	struct {
+ 		const struct btf *btf;
+ 		u32 id;
+ 	} cands[];
+ };
+ 
+ static void bpf_free_cands(struct bpf_cand_cache *cands)
+ {
+ 	if (!cands->cnt)
+ 		/* empty candidate array was allocated on stack */
+ 		return;
+ 	kfree(cands);
+ }
+ 
+ static void bpf_free_cands_from_cache(struct bpf_cand_cache *cands)
+ {
+ 	kfree(cands->name);
+ 	kfree(cands);
+ }
+ 
+ #define VMLINUX_CAND_CACHE_SIZE 31
+ static struct bpf_cand_cache *vmlinux_cand_cache[VMLINUX_CAND_CACHE_SIZE];
+ 
+ #define MODULE_CAND_CACHE_SIZE 31
+ static struct bpf_cand_cache *module_cand_cache[MODULE_CAND_CACHE_SIZE];
+ 
+ static DEFINE_MUTEX(cand_cache_mutex);
+ 
+ static void __print_cand_cache(struct bpf_verifier_log *log,
+ 			       struct bpf_cand_cache **cache,
+ 			       int cache_size)
+ {
+ 	struct bpf_cand_cache *cc;
+ 	int i, j;
+ 
+ 	for (i = 0; i < cache_size; i++) {
+ 		cc = cache[i];
+ 		if (!cc)
+ 			continue;
+ 		bpf_log(log, "[%d]%s(", i, cc->name);
+ 		for (j = 0; j < cc->cnt; j++) {
+ 			bpf_log(log, "%d", cc->cands[j].id);
+ 			if (j < cc->cnt - 1)
+ 				bpf_log(log, " ");
+ 		}
+ 		bpf_log(log, "), ");
+ 	}
+ }
+ 
+ static void print_cand_cache(struct bpf_verifier_log *log)
+ {
+ 	mutex_lock(&cand_cache_mutex);
+ 	bpf_log(log, "vmlinux_cand_cache:");
+ 	__print_cand_cache(log, vmlinux_cand_cache, VMLINUX_CAND_CACHE_SIZE);
+ 	bpf_log(log, "\nmodule_cand_cache:");
+ 	__print_cand_cache(log, module_cand_cache, MODULE_CAND_CACHE_SIZE);
+ 	bpf_log(log, "\n");
+ 	mutex_unlock(&cand_cache_mutex);
+ }
+ 
+ static u32 hash_cands(struct bpf_cand_cache *cands)
+ {
+ 	return jhash(cands->name, cands->name_len, 0);
+ }
+ 
+ static struct bpf_cand_cache *check_cand_cache(struct bpf_cand_cache *cands,
+ 					       struct bpf_cand_cache **cache,
+ 					       int cache_size)
+ {
+ 	struct bpf_cand_cache *cc = cache[hash_cands(cands) % cache_size];
+ 
+ 	if (cc && cc->name_len == cands->name_len &&
+ 	    !strncmp(cc->name, cands->name, cands->name_len))
+ 		return cc;
+ 	return NULL;
+ }
+ 
+ static size_t sizeof_cands(int cnt)
+ {
+ 	return offsetof(struct bpf_cand_cache, cands[cnt]);
+ }
+ 
+ static struct bpf_cand_cache *populate_cand_cache(struct bpf_cand_cache *cands,
+ 						  struct bpf_cand_cache **cache,
+ 						  int cache_size)
+ {
+ 	struct bpf_cand_cache **cc = &cache[hash_cands(cands) % cache_size], *new_cands;
+ 
+ 	if (*cc) {
+ 		bpf_free_cands_from_cache(*cc);
+ 		*cc = NULL;
+ 	}
+ 	new_cands = kmalloc(sizeof_cands(cands->cnt), GFP_KERNEL);
+ 	if (!new_cands) {
+ 		bpf_free_cands(cands);
+ 		return ERR_PTR(-ENOMEM);
+ 	}
+ 	memcpy(new_cands, cands, sizeof_cands(cands->cnt));
+ 	/* strdup the name, since it will stay in cache.
+ 	 * the cands->name points to strings in prog's BTF and the prog can be unloaded.
+ 	 */
+ 	new_cands->name = kmemdup_nul(cands->name, cands->name_len, GFP_KERNEL);
+ 	bpf_free_cands(cands);
+ 	if (!new_cands->name) {
+ 		kfree(new_cands);
+ 		return ERR_PTR(-ENOMEM);
+ 	}
+ 	*cc = new_cands;
+ 	return new_cands;
+ }
+ 
+ static void __purge_cand_cache(struct btf *btf, struct bpf_cand_cache **cache,
+ 			       int cache_size)
+ {
+ 	struct bpf_cand_cache *cc;
+ 	int i, j;
+ 
+ 	for (i = 0; i < cache_size; i++) {
+ 		cc = cache[i];
+ 		if (!cc)
+ 			continue;
+ 		if (!btf) {
+ 			/* when new module is loaded purge all of module_cand_cache,
+ 			 * since new module might have candidates with the name
+ 			 * that matches cached cands.
+ 			 */
+ 			bpf_free_cands_from_cache(cc);
+ 			cache[i] = NULL;
+ 			continue;
+ 		}
+ 		/* when module is unloaded purge cache entries
+ 		 * that match module's btf
+ 		 */
+ 		for (j = 0; j < cc->cnt; j++)
+ 			if (cc->cands[j].btf == btf) {
+ 				bpf_free_cands_from_cache(cc);
+ 				cache[i] = NULL;
+ 				break;
+ 			}
+ 	}
+ 
+ }
+ 
+ static void purge_cand_cache(struct btf *btf)
+ {
+ 	mutex_lock(&cand_cache_mutex);
+ 	__purge_cand_cache(btf, module_cand_cache, MODULE_CAND_CACHE_SIZE);
+ 	mutex_unlock(&cand_cache_mutex);
+ }
+ 
+ static struct bpf_cand_cache *
+ bpf_core_add_cands(struct bpf_cand_cache *cands, const struct btf *targ_btf,
+ 		   int targ_start_id)
+ {
+ 	struct bpf_cand_cache *new_cands;
+ 	const struct btf_type *t;
+ 	const char *targ_name;
+ 	size_t targ_essent_len;
+ 	int n, i;
+ 
+ 	n = btf_nr_types(targ_btf);
+ 	for (i = targ_start_id; i < n; i++) {
+ 		t = btf_type_by_id(targ_btf, i);
+ 		if (btf_kind(t) != cands->kind)
+ 			continue;
+ 
+ 		targ_name = btf_name_by_offset(targ_btf, t->name_off);
+ 		if (!targ_name)
+ 			continue;
+ 
+ 		/* the resched point is before strncmp to make sure that search
+ 		 * for non-existing name will have a chance to schedule().
+ 		 */
+ 		cond_resched();
+ 
+ 		if (strncmp(cands->name, targ_name, cands->name_len) != 0)
+ 			continue;
+ 
+ 		targ_essent_len = bpf_core_essential_name_len(targ_name);
+ 		if (targ_essent_len != cands->name_len)
+ 			continue;
+ 
+ 		/* most of the time there is only one candidate for a given kind+name pair */
+ 		new_cands = kmalloc(sizeof_cands(cands->cnt + 1), GFP_KERNEL);
+ 		if (!new_cands) {
+ 			bpf_free_cands(cands);
+ 			return ERR_PTR(-ENOMEM);
+ 		}
+ 
+ 		memcpy(new_cands, cands, sizeof_cands(cands->cnt));
+ 		bpf_free_cands(cands);
+ 		cands = new_cands;
+ 		cands->cands[cands->cnt].btf = targ_btf;
+ 		cands->cands[cands->cnt].id = i;
+ 		cands->cnt++;
+ 	}
+ 	return cands;
+ }
+ 
+ static struct bpf_cand_cache *
+ bpf_core_find_cands(struct bpf_core_ctx *ctx, u32 local_type_id)
+ {
+ 	struct bpf_cand_cache *cands, *cc, local_cand = {};
+ 	const struct btf *local_btf = ctx->btf;
+ 	const struct btf_type *local_type;
+ 	const struct btf *main_btf;
+ 	size_t local_essent_len;
+ 	struct btf *mod_btf;
+ 	const char *name;
+ 	int id;
+ 
+ 	main_btf = bpf_get_btf_vmlinux();
+ 	if (IS_ERR(main_btf))
+ 		return (void *)main_btf;
+ 
+ 	local_type = btf_type_by_id(local_btf, local_type_id);
+ 	if (!local_type)
+ 		return ERR_PTR(-EINVAL);
+ 
+ 	name = btf_name_by_offset(local_btf, local_type->name_off);
+ 	if (str_is_empty(name))
+ 		return ERR_PTR(-EINVAL);
+ 	local_essent_len = bpf_core_essential_name_len(name);
+ 
+ 	cands = &local_cand;
+ 	cands->name = name;
+ 	cands->kind = btf_kind(local_type);
+ 	cands->name_len = local_essent_len;
+ 
+ 	cc = check_cand_cache(cands, vmlinux_cand_cache, VMLINUX_CAND_CACHE_SIZE);
+ 	/* cands is a pointer to stack here */
+ 	if (cc) {
+ 		if (cc->cnt)
+ 			return cc;
+ 		goto check_modules;
+ 	}
+ 
+ 	/* Attempt to find target candidates in vmlinux BTF first */
+ 	cands = bpf_core_add_cands(cands, main_btf, 1);
+ 	if (IS_ERR(cands))
+ 		return cands;
+ 
+ 	/* cands is a pointer to kmalloced memory here if cands->cnt > 0 */
+ 
+ 	/* populate cache even when cands->cnt == 0 */
+ 	cc = populate_cand_cache(cands, vmlinux_cand_cache, VMLINUX_CAND_CACHE_SIZE);
+ 	if (IS_ERR(cc))
+ 		return cc;
+ 
+ 	/* if vmlinux BTF has any candidate, don't go for module BTFs */
+ 	if (cc->cnt)
+ 		return cc;
+ 
+ check_modules:
+ 	/* cands is a pointer to stack here and cands->cnt == 0 */
+ 	cc = check_cand_cache(cands, module_cand_cache, MODULE_CAND_CACHE_SIZE);
+ 	if (cc)
+ 		/* if cache has it return it even if cc->cnt == 0 */
+ 		return cc;
+ 
+ 	/* If candidate is not found in vmlinux's BTF then search in module's BTFs */
+ 	spin_lock_bh(&btf_idr_lock);
+ 	idr_for_each_entry(&btf_idr, mod_btf, id) {
+ 		if (!btf_is_module(mod_btf))
+ 			continue;
+ 		/* linear search could be slow hence unlock/lock
+ 		 * the IDR to avoiding holding it for too long
+ 		 */
+ 		btf_get(mod_btf);
+ 		spin_unlock_bh(&btf_idr_lock);
+ 		cands = bpf_core_add_cands(cands, mod_btf, btf_nr_types(main_btf));
+ 		if (IS_ERR(cands)) {
+ 			btf_put(mod_btf);
+ 			return cands;
+ 		}
+ 		spin_lock_bh(&btf_idr_lock);
+ 		btf_put(mod_btf);
+ 	}
+ 	spin_unlock_bh(&btf_idr_lock);
+ 	/* cands is a pointer to kmalloced memory here if cands->cnt > 0
+ 	 * or pointer to stack if cands->cnd == 0.
+ 	 * Copy it into the cache even when cands->cnt == 0 and
+ 	 * return the result.
+ 	 */
+ 	return populate_cand_cache(cands, module_cand_cache, MODULE_CAND_CACHE_SIZE);
+ }
+ 
+ int bpf_core_apply(struct bpf_core_ctx *ctx, const struct bpf_core_relo *relo,
+ 		   int relo_idx, void *insn)
+ {
+ 	bool need_cands = relo->kind != BPF_CORE_TYPE_ID_LOCAL;
+ 	struct bpf_core_cand_list cands = {};
+ 	struct bpf_core_spec *specs;
+ 	int err;
+ 
+ 	/* ~4k of temp memory necessary to convert LLVM spec like "0:1:0:5"
+ 	 * into arrays of btf_ids of struct fields and array indices.
+ 	 */
+ 	specs = kcalloc(3, sizeof(*specs), GFP_KERNEL);
+ 	if (!specs)
+ 		return -ENOMEM;
+ 
+ 	if (need_cands) {
+ 		struct bpf_cand_cache *cc;
+ 		int i;
+ 
+ 		mutex_lock(&cand_cache_mutex);
+ 		cc = bpf_core_find_cands(ctx, relo->type_id);
+ 		if (IS_ERR(cc)) {
+ 			bpf_log(ctx->log, "target candidate search failed for %d\n",
+ 				relo->type_id);
+ 			err = PTR_ERR(cc);
+ 			goto out;
+ 		}
+ 		if (cc->cnt) {
+ 			cands.cands = kcalloc(cc->cnt, sizeof(*cands.cands), GFP_KERNEL);
+ 			if (!cands.cands) {
+ 				err = -ENOMEM;
+ 				goto out;
+ 			}
+ 		}
+ 		for (i = 0; i < cc->cnt; i++) {
+ 			bpf_log(ctx->log,
+ 				"CO-RE relocating %s %s: found target candidate [%d]\n",
+ 				btf_kind_str[cc->kind], cc->name, cc->cands[i].id);
+ 			cands.cands[i].btf = cc->cands[i].btf;
+ 			cands.cands[i].id = cc->cands[i].id;
+ 		}
+ 		cands.len = cc->cnt;
+ 		/* cand_cache_mutex needs to span the cache lookup and
+ 		 * copy of btf pointer into bpf_core_cand_list,
+ 		 * since module can be unloaded while bpf_core_apply_relo_insn
+ 		 * is working with module's btf.
+ 		 */
+ 	}
+ 
+ 	err = bpf_core_apply_relo_insn((void *)ctx->log, insn, relo->insn_off / 8,
+ 				       relo, relo_idx, ctx->btf, &cands, specs);
+ out:
+ 	kfree(specs);
+ 	if (need_cands) {
+ 		kfree(cands.cands);
+ 		mutex_unlock(&cand_cache_mutex);
+ 		if (ctx->log->level & BPF_LOG_LEVEL2)
+ 			print_cand_cache(ctx->log);
+ 	}
+ 	return err;
+ }

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