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: 1334 bytes --]

Hi all,

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

  tools/lib/bpf/libbpf.c

between commit:

  3597683c9da6 ("tools: bpf: handle NULL return in bpf_prog_load_xattr()")

from the bpf tree and commit:

  17387dd5ac2c ("tools: bpf: don't complain about no kernel version for networking code")

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/libbpf.c
index 8da4eeb101a6,df54c4c9e48a..000000000000
--- a/tools/lib/bpf/libbpf.c
+++ b/tools/lib/bpf/libbpf.c
@@@ -2163,9 -2193,12 +2193,12 @@@ int bpf_prog_load_xattr(const struct bp
  
  	if (!attr)
  		return -EINVAL;
+ 	if (!attr->file)
+ 		return -EINVAL;
  
- 	obj = bpf_object__open(attr->file);
+ 	obj = __bpf_object__open(attr->file, NULL, 0,
+ 				 bpf_prog_type__needs_kver(attr->prog_type));
 -	if (IS_ERR(obj))
 +	if (IS_ERR_OR_NULL(obj))
  		return -ENOENT;
  
  	bpf_object__for_each_program(prog, obj) {

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

[Jakub Kicinski]

On Mon, 14 May 2018 11:57:00 +1000, Stephen Rothwell wrote:
> diff --cc tools/lib/bpf/libbpf.c
> index 8da4eeb101a6,df54c4c9e48a..000000000000
> --- a/tools/lib/bpf/libbpf.c
> +++ b/tools/lib/bpf/libbpf.c
> @@@ -2163,9 -2193,12 +2193,12 @@@ int bpf_prog_load_xattr(const struct bp
>   
>   	if (!attr)
>   		return -EINVAL;
> + 	if (!attr->file)
> + 		return -EINVAL;
>   
> - 	obj = bpf_object__open(attr->file);
> + 	obj = __bpf_object__open(attr->file, NULL, 0,
> + 				 bpf_prog_type__needs_kver(attr->prog_type));
>  -	if (IS_ERR(obj))
>  +	if (IS_ERR_OR_NULL(obj))
>   		return -ENOENT;

This is okay, thanks.  The OR_NULL is unnecessary just using the
bpf-next code is a better merge IMO.

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

[Stephen Rothwell]

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

Hi Jakub,

On Mon, 14 May 2018 13:41:40 -0700 Jakub Kicinski <jakub.kicinski@netronome.com> wrote:
>
> On Mon, 14 May 2018 11:57:00 +1000, Stephen Rothwell wrote:
> > diff --cc tools/lib/bpf/libbpf.c
> > index 8da4eeb101a6,df54c4c9e48a..000000000000
> > --- a/tools/lib/bpf/libbpf.c
> > +++ b/tools/lib/bpf/libbpf.c
> > @@@ -2163,9 -2193,12 +2193,12 @@@ int bpf_prog_load_xattr(const struct bp
> >   
> >   	if (!attr)
> >   		return -EINVAL;
> > + 	if (!attr->file)
> > + 		return -EINVAL;
> >   
> > - 	obj = bpf_object__open(attr->file);
> > + 	obj = __bpf_object__open(attr->file, NULL, 0,
> > + 				 bpf_prog_type__needs_kver(attr->prog_type));
> >  -	if (IS_ERR(obj))
> >  +	if (IS_ERR_OR_NULL(obj))
> >   		return -ENOENT;  
> 
> This is okay, thanks.  The OR_NULL is unnecessary just using the
> bpf-next code is a better merge IMO.

Thanks, I have updated my merge resolution from today.

-- 
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: 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 --]

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

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

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

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: 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: 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 --]

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

[Stephen Rothwell]

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

Hi all,

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

  tools/lib/bpf/btf.c

between commit:

  1245008122d7 ("libbpf: Fix native endian assumption when parsing BTF")

from the bpf tree and commit:

  3289959b97ca ("libbpf: Support BTF loading and raw data output in both endianness")

from the bpf-next tree.

I fixed it up (I used the latter version) 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

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

[Stephen Rothwell]

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

Hi all,

On Wed, 30 Sep 2020 14:07:15 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Today's linux-next merge of the bpf-next tree got a conflict in:
> 
>   tools/lib/bpf/btf.c
> 
> between commit:
> 
>   1245008122d7 ("libbpf: Fix native endian assumption when parsing BTF")
> 
> from the bpf tree and commit:
> 
>   3289959b97ca ("libbpf: Support BTF loading and raw data output in both endianness")
> 
> from the bpf-next tree.
> 
> I fixed it up (I used the latter version) 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.

This is now a conflict between the net-next and net trees.
-- 
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: 1792 bytes --]

Hi all,

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

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

between commits:

  9c82a63cf370 ("libbpf: Fix CO-RE relocs against .text section")
  647b502e3d54 ("selftests/bpf: Refactor some net macros to bpf_tracing_net.h")

from the bpf tree and commit:

  84544f5637ff ("selftests/bpf: Move newer bpf_iter_* type redefining to a new header file")

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/bpf_iter_netlink.c
index 75ecf956a2df,cec82a419800..000000000000
--- a/tools/testing/selftests/bpf/progs/bpf_iter_netlink.c
+++ b/tools/testing/selftests/bpf/progs/bpf_iter_netlink.c
@@@ -11,21 -7,7 +7,7 @@@
  
  char _license[] SEC("license") = "GPL";
  
- #define sk_rmem_alloc	sk_backlog.rmem_alloc
- #define sk_refcnt	__sk_common.skc_refcnt
- 
- struct bpf_iter_meta {
- 	struct seq_file *seq;
- 	__u64 session_id;
- 	__u64 seq_num;
- } __attribute__((preserve_access_index));
- 
- struct bpf_iter__netlink {
- 	struct bpf_iter_meta *meta;
- 	struct netlink_sock *sk;
- } __attribute__((preserve_access_index));
- 
 -static inline struct inode *SOCK_INODE(struct socket *socket)
 +static __attribute__((noinline)) struct inode *SOCK_INODE(struct socket *socket)
  {
  	return &container_of(socket, struct socket_alloc, socket)->vfs_inode;
  }

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

[Stephen Rothwell]

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

Hi all,

On Fri, 26 Jun 2020 10:05:27 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Today's linux-next merge of the bpf-next tree got a conflict in:
> 
>   tools/testing/selftests/bpf/progs/bpf_iter_netlink.c
> 
> between commits:
> 
>   9c82a63cf370 ("libbpf: Fix CO-RE relocs against .text section")
>   647b502e3d54 ("selftests/bpf: Refactor some net macros to bpf_tracing_net.h")
> 
> from the bpf tree and commit:
> 
>   84544f5637ff ("selftests/bpf: Move newer bpf_iter_* type redefining to a new header file")
> 
> 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.
> 
> diff --cc tools/testing/selftests/bpf/progs/bpf_iter_netlink.c
> index 75ecf956a2df,cec82a419800..000000000000
> --- a/tools/testing/selftests/bpf/progs/bpf_iter_netlink.c
> +++ b/tools/testing/selftests/bpf/progs/bpf_iter_netlink.c
> @@@ -11,21 -7,7 +7,7 @@@
>   
>   char _license[] SEC("license") = "GPL";
>   
> - #define sk_rmem_alloc	sk_backlog.rmem_alloc
> - #define sk_refcnt	__sk_common.skc_refcnt
> - 
> - struct bpf_iter_meta {
> - 	struct seq_file *seq;
> - 	__u64 session_id;
> - 	__u64 seq_num;
> - } __attribute__((preserve_access_index));
> - 
> - struct bpf_iter__netlink {
> - 	struct bpf_iter_meta *meta;
> - 	struct netlink_sock *sk;
> - } __attribute__((preserve_access_index));
> - 
>  -static inline struct inode *SOCK_INODE(struct socket *socket)
>  +static __attribute__((noinline)) struct inode *SOCK_INODE(struct socket *socket)
>   {
>   	return &container_of(socket, struct socket_alloc, socket)->vfs_inode;
>   }

This is now a conflict between net-next tree and the net 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: 748 bytes --]

Hi all,

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

  kernel/bpf/verifier.c

between commit:

  e92888c72fbd ("bpf: Enforce returning 0 for fentry/fexit progs")

from the bpf tree and commit:

  15d83c4d7cef ("bpf: Allow loading of a bpf_iter program")

from the bpf-next tree.

I fixed it up (I just used the latter version) 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

[-- 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: 3752 bytes --]

Hi all,

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

  tools/lib/bpf/Makefile

between commit:

  1bd63524593b ("libbpf: handle symbol versioning properly for libbpf.a")

from the bpf tree and commit:

  e01a75c15969 ("libbpf: Move bpf_{helpers, helper_defs, endian, tracing}.h into libbpf")

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/Makefile
index 56ce6292071b,1270955e4845..000000000000
--- a/tools/lib/bpf/Makefile
+++ b/tools/lib/bpf/Makefile
@@@ -143,7 -133,9 +143,9 @@@ LIB_TARGET	:= $(addprefix $(OUTPUT),$(L
  LIB_FILE	:= $(addprefix $(OUTPUT),$(LIB_FILE))
  PC_FILE		:= $(addprefix $(OUTPUT),$(PC_FILE))
  
+ TAGS_PROG := $(if $(shell which etags 2>/dev/null),etags,ctags)
+ 
 -GLOBAL_SYM_COUNT = $(shell readelf -s --wide $(BPF_IN) | \
 +GLOBAL_SYM_COUNT = $(shell readelf -s --wide $(BPF_IN_SHARED) | \
  			   cut -d "@" -f1 | sed 's/_v[0-9]_[0-9]_[0-9].*//' | \
  			   awk '/GLOBAL/ && /DEFAULT/ && !/UND/ {print $$8}' | \
  			   sort -u | wc -l)
@@@ -165,7 -157,7 +167,7 @@@ all: fixde
  
  all_cmd: $(CMD_TARGETS) check
  
- $(BPF_IN_SHARED): force elfdep bpfdep
 -$(BPF_IN): force elfdep bpfdep bpf_helper_defs.h
++$(BPF_IN_SHARED): force elfdep bpfdep bpf_helper_defs.h
  	@(test -f ../../include/uapi/linux/bpf.h -a -f ../../../include/uapi/linux/bpf.h && ( \
  	(diff -B ../../include/uapi/linux/bpf.h ../../../include/uapi/linux/bpf.h >/dev/null) || \
  	echo "Warning: Kernel ABI header at 'tools/include/uapi/linux/bpf.h' differs from latest version at 'include/uapi/linux/bpf.h'" >&2 )) || true
@@@ -181,14 -173,15 +183,18 @@@
  	@(test -f ../../include/uapi/linux/if_xdp.h -a -f ../../../include/uapi/linux/if_xdp.h && ( \
  	(diff -B ../../include/uapi/linux/if_xdp.h ../../../include/uapi/linux/if_xdp.h >/dev/null) || \
  	echo "Warning: Kernel ABI header at 'tools/include/uapi/linux/if_xdp.h' differs from latest version at 'include/uapi/linux/if_xdp.h'" >&2 )) || true
 -	$(Q)$(MAKE) $(build)=libbpf
 +	$(Q)$(MAKE) $(build)=libbpf OUTPUT=$(SHARED_OBJDIR) CFLAGS="$(CFLAGS) $(SHLIB_FLAGS)"
 +
 +$(BPF_IN_STATIC): force elfdep bpfdep
 +	$(Q)$(MAKE) $(build)=libbpf OUTPUT=$(STATIC_OBJDIR)
  
+ bpf_helper_defs.h: $(srctree)/include/uapi/linux/bpf.h
+ 	$(Q)$(srctree)/scripts/bpf_helpers_doc.py --header 		\
+ 		--file $(srctree)/include/uapi/linux/bpf.h > bpf_helper_defs.h
+ 
  $(OUTPUT)libbpf.so: $(OUTPUT)libbpf.so.$(LIBBPF_VERSION)
  
 -$(OUTPUT)libbpf.so.$(LIBBPF_VERSION): $(BPF_IN)
 +$(OUTPUT)libbpf.so.$(LIBBPF_VERSION): $(BPF_IN_SHARED)
  	$(QUIET_LINK)$(CC) --shared -Wl,-soname,libbpf.so.$(LIBBPF_MAJOR_VERSION) \
  				    -Wl,--version-script=$(VERSION_SCRIPT) $^ -lelf -o $@
  	@ln -sf $(@F) $(OUTPUT)libbpf.so
@@@ -268,9 -266,9 +279,10 @@@ config-clean
  	$(Q)$(MAKE) -C $(srctree)/tools/build/feature/ clean >/dev/null
  
  clean:
 -	$(call QUIET_CLEAN, libbpf) $(RM) $(TARGETS) $(CXX_TEST_TARGET) \
 +	$(call QUIET_CLEAN, libbpf) $(RM) -rf $(TARGETS) $(CXX_TEST_TARGET) \
  		*.o *~ *.a *.so *.so.$(LIBBPF_MAJOR_VERSION) .*.d .*.cmd \
- 		*.pc LIBBPF-CFLAGS $(SHARED_OBJDIR) $(STATIC_OBJDIR)
 -		*.pc LIBBPF-CFLAGS bpf_helper_defs.h
++		*.pc LIBBPF-CFLAGS $(SHARED_OBJDIR) $(STATIC_OBJDIR) \
++		bpf_helper_defs.h
  	$(call QUIET_CLEAN, core-gen) $(RM) $(OUTPUT)FEATURE-DUMP.libbpf
  
  

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

[Stephen Rothwell]

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

Hi all,

This is now a conflict between the net and net-next trees.

On Wed, 9 Oct 2019 09:47:25 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Today's linux-next merge of the bpf-next tree got a conflict in:
> 
>   tools/lib/bpf/Makefile
> 
> between commit:
> 
>   1bd63524593b ("libbpf: handle symbol versioning properly for libbpf.a")
> 
> from the bpf tree and commit:
> 
>   e01a75c15969 ("libbpf: Move bpf_{helpers, helper_defs, endian, tracing}.h into libbpf")
> 
> 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/Makefile
> index 56ce6292071b,1270955e4845..000000000000
> --- a/tools/lib/bpf/Makefile
> +++ b/tools/lib/bpf/Makefile
> @@@ -143,7 -133,9 +143,9 @@@ LIB_TARGET	:= $(addprefix $(OUTPUT),$(L
>   LIB_FILE	:= $(addprefix $(OUTPUT),$(LIB_FILE))
>   PC_FILE		:= $(addprefix $(OUTPUT),$(PC_FILE))
>   
> + TAGS_PROG := $(if $(shell which etags 2>/dev/null),etags,ctags)
> + 
>  -GLOBAL_SYM_COUNT = $(shell readelf -s --wide $(BPF_IN) | \
>  +GLOBAL_SYM_COUNT = $(shell readelf -s --wide $(BPF_IN_SHARED) | \
>   			   cut -d "@" -f1 | sed 's/_v[0-9]_[0-9]_[0-9].*//' | \
>   			   awk '/GLOBAL/ && /DEFAULT/ && !/UND/ {print $$8}' | \
>   			   sort -u | wc -l)
> @@@ -165,7 -157,7 +167,7 @@@ all: fixde
>   
>   all_cmd: $(CMD_TARGETS) check
>   
> - $(BPF_IN_SHARED): force elfdep bpfdep
>  -$(BPF_IN): force elfdep bpfdep bpf_helper_defs.h
> ++$(BPF_IN_SHARED): force elfdep bpfdep bpf_helper_defs.h
>   	@(test -f ../../include/uapi/linux/bpf.h -a -f ../../../include/uapi/linux/bpf.h && ( \
>   	(diff -B ../../include/uapi/linux/bpf.h ../../../include/uapi/linux/bpf.h >/dev/null) || \
>   	echo "Warning: Kernel ABI header at 'tools/include/uapi/linux/bpf.h' differs from latest version at 'include/uapi/linux/bpf.h'" >&2 )) || true
> @@@ -181,14 -173,15 +183,18 @@@
>   	@(test -f ../../include/uapi/linux/if_xdp.h -a -f ../../../include/uapi/linux/if_xdp.h && ( \
>   	(diff -B ../../include/uapi/linux/if_xdp.h ../../../include/uapi/linux/if_xdp.h >/dev/null) || \
>   	echo "Warning: Kernel ABI header at 'tools/include/uapi/linux/if_xdp.h' differs from latest version at 'include/uapi/linux/if_xdp.h'" >&2 )) || true
>  -	$(Q)$(MAKE) $(build)=libbpf
>  +	$(Q)$(MAKE) $(build)=libbpf OUTPUT=$(SHARED_OBJDIR) CFLAGS="$(CFLAGS) $(SHLIB_FLAGS)"
>  +
>  +$(BPF_IN_STATIC): force elfdep bpfdep
>  +	$(Q)$(MAKE) $(build)=libbpf OUTPUT=$(STATIC_OBJDIR)
>   
> + bpf_helper_defs.h: $(srctree)/include/uapi/linux/bpf.h
> + 	$(Q)$(srctree)/scripts/bpf_helpers_doc.py --header 		\
> + 		--file $(srctree)/include/uapi/linux/bpf.h > bpf_helper_defs.h
> + 
>   $(OUTPUT)libbpf.so: $(OUTPUT)libbpf.so.$(LIBBPF_VERSION)
>   
>  -$(OUTPUT)libbpf.so.$(LIBBPF_VERSION): $(BPF_IN)
>  +$(OUTPUT)libbpf.so.$(LIBBPF_VERSION): $(BPF_IN_SHARED)
>   	$(QUIET_LINK)$(CC) --shared -Wl,-soname,libbpf.so.$(LIBBPF_MAJOR_VERSION) \
>   				    -Wl,--version-script=$(VERSION_SCRIPT) $^ -lelf -o $@
>   	@ln -sf $(@F) $(OUTPUT)libbpf.so
> @@@ -268,9 -266,9 +279,10 @@@ config-clean
>   	$(Q)$(MAKE) -C $(srctree)/tools/build/feature/ clean >/dev/null
>   
>   clean:
>  -	$(call QUIET_CLEAN, libbpf) $(RM) $(TARGETS) $(CXX_TEST_TARGET) \
>  +	$(call QUIET_CLEAN, libbpf) $(RM) -rf $(TARGETS) $(CXX_TEST_TARGET) \
>   		*.o *~ *.a *.so *.so.$(LIBBPF_MAJOR_VERSION) .*.d .*.cmd \
> - 		*.pc LIBBPF-CFLAGS $(SHARED_OBJDIR) $(STATIC_OBJDIR)
>  -		*.pc LIBBPF-CFLAGS bpf_helper_defs.h
> ++		*.pc LIBBPF-CFLAGS $(SHARED_OBJDIR) $(STATIC_OBJDIR) \
> ++		bpf_helper_defs.h
>   	$(call QUIET_CLEAN, core-gen) $(RM) $(OUTPUT)FEATURE-DUMP.libbpf
>   
>   

-- 
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: 1411 bytes --]

Hi all,

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

  tools/lib/bpf/Makefile

between commit:

  1bd63524593b ("libbpf: handle symbol versioning properly for libbpf.a")

from the bpf tree and commit:

  a9eb048d5615 ("libbpf: Add cscope and tags targets to Makefile")

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/Makefile
index 56ce6292071b,10b77644a17c..000000000000
--- a/tools/lib/bpf/Makefile
+++ b/tools/lib/bpf/Makefile
@@@ -143,7 -133,9 +143,9 @@@ LIB_TARGET	:= $(addprefix $(OUTPUT),$(L
  LIB_FILE	:= $(addprefix $(OUTPUT),$(LIB_FILE))
  PC_FILE		:= $(addprefix $(OUTPUT),$(PC_FILE))
  
+ TAGS_PROG := $(if $(shell which etags 2>/dev/null),etags,ctags)
+ 
 -GLOBAL_SYM_COUNT = $(shell readelf -s --wide $(BPF_IN) | \
 +GLOBAL_SYM_COUNT = $(shell readelf -s --wide $(BPF_IN_SHARED) | \
  			   cut -d "@" -f1 | sed 's/_v[0-9]_[0-9]_[0-9].*//' | \
  			   awk '/GLOBAL/ && /DEFAULT/ && !/UND/ {print $$8}' | \
  			   sort -u | wc -l)

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

[Stephen Rothwell]

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

Hi all,

This is now a conflict between the net and net-next trees.

On Tue, 8 Oct 2019 09:48:40 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Today's linux-next merge of the bpf-next tree got a conflict in:
> 
>   tools/lib/bpf/Makefile
> 
> between commit:
> 
>   1bd63524593b ("libbpf: handle symbol versioning properly for libbpf.a")
> 
> from the bpf tree and commit:
> 
>   a9eb048d5615 ("libbpf: Add cscope and tags targets to Makefile")
> 
> 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/Makefile
> index 56ce6292071b,10b77644a17c..000000000000
> --- a/tools/lib/bpf/Makefile
> +++ b/tools/lib/bpf/Makefile
> @@@ -143,7 -133,9 +143,9 @@@ LIB_TARGET	:= $(addprefix $(OUTPUT),$(L
>   LIB_FILE	:= $(addprefix $(OUTPUT),$(LIB_FILE))
>   PC_FILE		:= $(addprefix $(OUTPUT),$(PC_FILE))
>   
> + TAGS_PROG := $(if $(shell which etags 2>/dev/null),etags,ctags)
> + 
>  -GLOBAL_SYM_COUNT = $(shell readelf -s --wide $(BPF_IN) | \
>  +GLOBAL_SYM_COUNT = $(shell readelf -s --wide $(BPF_IN_SHARED) | \
>   			   cut -d "@" -f1 | sed 's/_v[0-9]_[0-9]_[0-9].*//' | \
>   			   awk '/GLOBAL/ && /DEFAULT/ && !/UND/ {print $$8}' | \
>   			   sort -u | wc -l)

-- 
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: 1555 bytes --]

Hi all,

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

  tools/bpf/bpftool/map.c

between commit:

  e0665239e07f ("bpftool: Fix errno variable usage")

from the bpf tree and commit:

  0478c3bf8124 ("bpftool: Use print_entry_error() in case of ENOENT when dumping")

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/bpf/bpftool/map.c
index 1744bf61a0b8,44b192e87708..000000000000
--- a/tools/bpf/bpftool/map.c
+++ b/tools/bpf/bpftool/map.c
@@@ -722,11 -715,16 +715,16 @@@ static int dump_map_elem(int fd, void *
  		jsonw_string_field(json_wtr, "error", strerror(lookup_errno));
  		jsonw_end_object(json_wtr);
  	} else {
+ 		const char *msg = NULL;
+ 
 -		if (errno == ENOENT)
 +		if (lookup_errno == ENOENT)
- 			print_entry_plain(map_info, key, NULL);
- 		else
- 			print_entry_error(map_info, key,
- 					  strerror(lookup_errno));
+ 			msg = "<no entry>";
+ 		else if (lookup_errno == ENOSPC &&
+ 			 map_info->type == BPF_MAP_TYPE_REUSEPORT_SOCKARRAY)
+ 			msg = "<cannot read>";
+ 
+ 		print_entry_error(map_info, key,
+ 				  msg ? : strerror(lookup_errno));
  	}
  
  	return 0;

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

[Stephen Rothwell]

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

Hi all,

On Wed, 17 Apr 2019 11:08:56 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Today's linux-next merge of the bpf-next tree got a conflict in:
> 
>   tools/bpf/bpftool/map.c
> 
> between commit:
> 
>   e0665239e07f ("bpftool: Fix errno variable usage")
> 
> from the bpf tree and commit:
> 
>   0478c3bf8124 ("bpftool: Use print_entry_error() in case of ENOENT when dumping")
> 
> from the bpf-next tree.
> 
> diff --cc tools/bpf/bpftool/map.c
> index 1744bf61a0b8,44b192e87708..000000000000
> --- a/tools/bpf/bpftool/map.c
> +++ b/tools/bpf/bpftool/map.c
> @@@ -722,11 -715,16 +715,16 @@@ static int dump_map_elem(int fd, void *
>   		jsonw_string_field(json_wtr, "error", strerror(lookup_errno));
>   		jsonw_end_object(json_wtr);
>   	} else {
> + 		const char *msg = NULL;
> + 
>  -		if (errno == ENOENT)
>  +		if (lookup_errno == ENOENT)
> - 			print_entry_plain(map_info, key, NULL);
> - 		else
> - 			print_entry_error(map_info, key,
> - 					  strerror(lookup_errno));
> + 			msg = "<no entry>";
> + 		else if (lookup_errno == ENOSPC &&
> + 			 map_info->type == BPF_MAP_TYPE_REUSEPORT_SOCKARRAY)
> + 			msg = "<cannot read>";
> + 
> + 		print_entry_error(map_info, key,
> + 				  msg ? : strerror(lookup_errno));
>   	}
>   
>   	return 0;

This is now a conflict between the net-next and bpf trees.

-- 
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: 2797 bytes --]

Hi all,

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

  net/core/filter.c

between commit:

  b7df9ada9a77 ("bpf: fix pointer offsets in context for 32 bit")

from the bpf tree and commit:

  e3da08d05700 ("bpf: allow BPF read access to qdisc pkt_len")

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 net/core/filter.c
index 8659b40172d1,3d54af4c363d..000000000000
--- a/net/core/filter.c
+++ b/net/core/filter.c
@@@ -5771,9 -5770,10 +5771,10 @@@ static bool sk_filter_is_valid_access(i
  	case bpf_ctx_range(struct __sk_buff, data):
  	case bpf_ctx_range(struct __sk_buff, data_meta):
  	case bpf_ctx_range(struct __sk_buff, data_end):
 -	case bpf_ctx_range(struct __sk_buff, flow_keys):
 +	case bpf_ctx_range_ptr(struct __sk_buff, flow_keys):
  	case bpf_ctx_range_till(struct __sk_buff, family, local_port):
  	case bpf_ctx_range(struct __sk_buff, tstamp):
+ 	case bpf_ctx_range(struct __sk_buff, wire_len):
  		return false;
  	}
  
@@@ -5797,7 -5797,8 +5798,8 @@@ static bool cg_skb_is_valid_access(int 
  	switch (off) {
  	case bpf_ctx_range(struct __sk_buff, tc_classid):
  	case bpf_ctx_range(struct __sk_buff, data_meta):
 -	case bpf_ctx_range(struct __sk_buff, flow_keys):
 +	case bpf_ctx_range_ptr(struct __sk_buff, flow_keys):
+ 	case bpf_ctx_range(struct __sk_buff, wire_len):
  		return false;
  	case bpf_ctx_range(struct __sk_buff, data):
  	case bpf_ctx_range(struct __sk_buff, data_end):
@@@ -5842,8 -5843,9 +5844,9 @@@ static bool lwt_is_valid_access(int off
  	case bpf_ctx_range(struct __sk_buff, tc_classid):
  	case bpf_ctx_range_till(struct __sk_buff, family, local_port):
  	case bpf_ctx_range(struct __sk_buff, data_meta):
 -	case bpf_ctx_range(struct __sk_buff, flow_keys):
 +	case bpf_ctx_range_ptr(struct __sk_buff, flow_keys):
  	case bpf_ctx_range(struct __sk_buff, tstamp):
+ 	case bpf_ctx_range(struct __sk_buff, wire_len):
  		return false;
  	}
  
@@@ -6272,8 -6274,9 +6275,9 @@@ static bool sk_skb_is_valid_access(int 
  	switch (off) {
  	case bpf_ctx_range(struct __sk_buff, tc_classid):
  	case bpf_ctx_range(struct __sk_buff, data_meta):
 -	case bpf_ctx_range(struct __sk_buff, flow_keys):
 +	case bpf_ctx_range_ptr(struct __sk_buff, flow_keys):
  	case bpf_ctx_range(struct __sk_buff, tstamp):
+ 	case bpf_ctx_range(struct __sk_buff, wire_len):
  		return false;
  	}
  

[-- 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: 3370 bytes --]

Hi all,

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

  include/uapi/linux/bpf.h

between commit:

  d74286d2c25a ("bpf: Improve socket lookup reuseport documentation")

from the bpf tree and commit:

  90b1023f68c7 ("bpf: fix documentation for eBPF helpers")

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/uapi/linux/bpf.h
index ec8b40ff386e,572eb2d42768..000000000000
--- a/include/uapi/linux/bpf.h
+++ b/include/uapi/linux/bpf.h
@@@ -2209,11 -2210,11 +2212,11 @@@ union bpf_attr 
   *		This helper is available only if the kernel was compiled with
   *		**CONFIG_NET** configuration option.
   *	Return
-  *		Pointer to *struct bpf_sock*, or NULL in case of failure.
-  *		For sockets with reuseport option, the *struct bpf_sock*
-  *		result is from reuse->socks[] using the hash of the tuple.
+  *		A pointer to *struct bpf_sock*, or **NULL** in case of failure.
 - *		For sockets with reuseport option, **struct bpf_sock**
++ *		For sockets with reuseport option, the **struct bpf_sock**
+  *		return is from **reuse->socks**\ [] using hash of the packet.
   *
 - * struct bpf_sock *bpf_sk_lookup_udp(void *ctx, struct bpf_sock_tuple *tuple, u32 tuple_size, u32 netns, u64 flags)
 + * struct bpf_sock *bpf_sk_lookup_udp(void *ctx, struct bpf_sock_tuple *tuple, u32 tuple_size, u64 netns, u64 flags)
   *	Description
   *		Look for UDP socket matching *tuple*, optionally in a child
   *		network namespace *netns*. The return value must be checked,
@@@ -2245,14 -2244,15 +2248,16 @@@
   *		This helper is available only if the kernel was compiled with
   *		**CONFIG_NET** configuration option.
   *	Return
-  *		Pointer to *struct bpf_sock*, or NULL in case of failure.
-  *		For sockets with reuseport option, the *struct bpf_sock*
-  *		result is from reuse->socks[] using the hash of the tuple.
+  *		A pointer to **struct bpf_sock**, or **NULL** in case of
 - *		failure. For sockets with reuseport option, **struct bpf_sock**
 - *		return is from **reuse->socks**\ [] using hash of the packet.
++ *		failure. For sockets with reuseport option, the
++ *		**struct bpf_sock** return is from **reuse->socks**\ []
++ *		using hash of the packet.
   *
-  * int bpf_sk_release(struct bpf_sock *sk)
+  * int bpf_sk_release(struct bpf_sock *sock)
   *	Description
-  *		Release the reference held by *sock*. *sock* must be a non-NULL
-  *		pointer that was returned from bpf_sk_lookup_xxx\ ().
+  *		Release the reference held by *sock*. *sock* must be a
+  *		non-**NULL** pointer that was returned from
+  *		**bpf_sk_lookup_xxx**\ ().
   *	Return
   *		0 on success, or a negative error in case of failure.
   *
@@@ -2494,8 -2495,9 +2509,9 @@@ struct __sk_buff 
  	/* ... here. */
  
  	__u32 data_meta;
 -	struct bpf_flow_keys *flow_keys;
 +	__bpf_md_ptr(struct bpf_flow_keys *, flow_keys);
  	__u64 tstamp;
+ 	__u32 wire_len;
  };
  
  struct bpf_tunnel_key {

[-- 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: 1751 bytes --]

Hi all,

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

  net/core/filter.c

between commit:

  b13b8787c95c ("bpf: Fix IPv6 dport byte order in bpf_sk_lookup_udp")

from the bpf tree and commit:

  c8123ead13a5 ("bpf: Extend the sk_lookup() helper to XDP hookpoint.")

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 net/core/filter.c
index 9a1327eb25fa,53d50fb75ea1..000000000000
--- a/net/core/filter.c
+++ b/net/core/filter.c
@@@ -4852,19 -4867,19 +4867,18 @@@ static struct sock *sk_lookup(struct ne
  	} else {
  		struct in6_addr *src6 = (struct in6_addr *)&tuple->ipv6.saddr;
  		struct in6_addr *dst6 = (struct in6_addr *)&tuple->ipv6.daddr;
- 		int sdif = inet6_sdif(skb);
 -		u16 hnum = ntohs(tuple->ipv6.dport);
  
  		if (proto == IPPROTO_TCP)
- 			sk = __inet6_lookup(net, &tcp_hashinfo, skb, 0,
+ 			sk = __inet6_lookup(net, &tcp_hashinfo, NULL, 0,
  					    src6, tuple->ipv6.sport,
 -					    dst6, hnum,
 +					    dst6, ntohs(tuple->ipv6.dport),
  					    dif, sdif, &refcounted);
  		else if (likely(ipv6_bpf_stub))
  			sk = ipv6_bpf_stub->udp6_lib_lookup(net,
  							    src6, tuple->ipv6.sport,
 -							    dst6, hnum,
 +							    dst6, tuple->ipv6.dport,
  							    dif, sdif,
- 							    &udp_table, skb);
+ 							    &udp_table, NULL);
  #endif
  	}
  

[-- 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: 2342 bytes --]

Hi all,

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

  tools/testing/selftests/bpf/test_progs.c

between commit:

  a4e21ff8d9a3 ("bpf: minor fix to selftest test_stacktrace_build_id()")

from the bpf tree and commit:

  79b453501310 ("tools/bpf: add a test for bpf_get_stack with tracepoint prog")

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/test_progs.c
index fac581f1c57f,aa336f0abebc..000000000000
--- a/tools/testing/selftests/bpf/test_progs.c
+++ b/tools/testing/selftests/bpf/test_progs.c
@@@ -1137,9 -1193,14 +1193,14 @@@ static void test_stacktrace_build_id(vo
  		  err, errno))
  		goto disable_pmu;
  
+ 	stack_amap_fd = bpf_find_map(__func__, obj, "stack_amap");
+ 	if (CHECK(stack_amap_fd < 0, "bpf_find_map stack_amap",
+ 		  "err %d errno %d\n", err, errno))
+ 		goto disable_pmu;
+ 
  	assert(system("dd if=/dev/urandom of=/dev/zero count=4 2> /dev/null")
  	       == 0);
 -	assert(system("./urandom_read if=/dev/urandom of=/dev/zero count=4 2> /dev/null") == 0);
 +	assert(system("./urandom_read") == 0);
  	/* disable stack trace collection */
  	key = 0;
  	val = 1;
@@@ -1188,8 -1249,15 +1249,15 @@@
  		previous_key = key;
  	} while (bpf_map_get_next_key(stackmap_fd, &previous_key, &key) == 0);
  
- 	CHECK(build_id_matches < 1, "build id match",
- 	      "Didn't find expected build ID from the map\n");
+ 	if (CHECK(build_id_matches < 1, "build id match",
 -		  "Didn't find expected build ID from the map"))
++		  "Didn't find expected build ID from the map\n"))
+ 		goto disable_pmu;
+ 
+ 	stack_trace_len = PERF_MAX_STACK_DEPTH
+ 		* sizeof(struct bpf_stack_build_id);
+ 	err = compare_stack_ips(stackmap_fd, stack_amap_fd, stack_trace_len);
+ 	CHECK(err, "compare_stack_ips stackmap vs. stack_amap",
+ 	      "err %d errno %d\n", err, errno);
  
  disable_pmu:
  	ioctl(pmu_fd, PERF_EVENT_IOC_DISABLE);

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

[Song Liu]

> On May 1, 2018, at 7:09 PM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> 
> Hi all,
> 
> Today's linux-next merge of the bpf-next tree got a conflict in:
> 
>  tools/testing/selftests/bpf/test_progs.c
> 
> between commit:
> 
>  a4e21ff8d9a3 ("bpf: minor fix to selftest test_stacktrace_build_id()")
> 
> from the bpf tree and commit:
> 
>  79b453501310 ("tools/bpf: add a test for bpf_get_stack with tracepoint prog")
> 
> 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/test_progs.c
> index fac581f1c57f,aa336f0abebc..000000000000
> --- a/tools/testing/selftests/bpf/test_progs.c
> +++ b/tools/testing/selftests/bpf/test_progs.c
> @@@ -1137,9 -1193,14 +1193,14 @@@ static void test_stacktrace_build_id(vo
>  		  err, errno))
>  		goto disable_pmu;
> 
> + 	stack_amap_fd = bpf_find_map(__func__, obj, "stack_amap");
> + 	if (CHECK(stack_amap_fd < 0, "bpf_find_map stack_amap",
> + 		  "err %d errno %d\n", err, errno))
> + 		goto disable_pmu;
> + 
>  	assert(system("dd if=/dev/urandom of=/dev/zero count=4 2> /dev/null")
>  	       == 0);
> -	assert(system("./urandom_read if=/dev/urandom of=/dev/zero count=4 2> /dev/null") == 0);
> +	assert(system("./urandom_read") == 0);
>  	/* disable stack trace collection */
>  	key = 0;
>  	val = 1;
> @@@ -1188,8 -1249,15 +1249,15 @@@
>  		previous_key = key;
>  	} while (bpf_map_get_next_key(stackmap_fd, &previous_key, &key) == 0);
> 
> - 	CHECK(build_id_matches < 1, "build id match",
> - 	      "Didn't find expected build ID from the map\n");
> + 	if (CHECK(build_id_matches < 1, "build id match",
> -		  "Didn't find expected build ID from the map"))
> ++		  "Didn't find expected build ID from the map\n"))

^^^  Is there a "+" at the beginning of this line? 

Thanks,
Song

> + 		goto disable_pmu;
> + 
> + 	stack_trace_len = PERF_MAX_STACK_DEPTH
> + 		* sizeof(struct bpf_stack_build_id);
> + 	err = compare_stack_ips(stackmap_fd, stack_amap_fd, stack_trace_len);
> + 	CHECK(err, "compare_stack_ips stackmap vs. stack_amap",
> + 	      "err %d errno %d\n", err, errno);
> 
>  disable_pmu:
>  	ioctl(pmu_fd, PERF_EVENT_IOC_DISABLE);

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

[Stephen Rothwell]

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

Hi Song,

On Wed, 2 May 2018 04:40:20 +0000 Song Liu <songliubraving@fb.com> wrote:
>
> > - 	CHECK(build_id_matches < 1, "build id match",
> > - 	      "Didn't find expected build ID from the map\n");
> > + 	if (CHECK(build_id_matches < 1, "build id match",
> > -		  "Didn't find expected build ID from the map"))
> > ++		  "Didn't find expected build ID from the map\n"))  
> 
> ^^^  Is there a "+" at the beginning of this line? 

No, this is a merge resolution diff, so the ++ means that the line did
not appear in either parent commit.

-- 
Cheers,
Stephen Rothwell

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

[Song Liu]

> On May 1, 2018, at 10:50 PM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> 
> Hi Song,
> 
> On Wed, 2 May 2018 04:40:20 +0000 Song Liu <songliubraving@fb.com> wrote:
>> 
>>> - 	CHECK(build_id_matches < 1, "build id match",
>>> - 	      "Didn't find expected build ID from the map\n");
>>> + 	if (CHECK(build_id_matches < 1, "build id match",
>>> -		  "Didn't find expected build ID from the map"))
>>> ++		  "Didn't find expected build ID from the map\n"))  
>> 
>> ^^^  Is there a "+" at the beginning of this line? 
> 
> No, this is a merge resolution diff, so the ++ means that the line did
> not appear in either parent commit.

Hi Stephen,

Thanks for the explanation! 

Song

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

[Stephen Rothwell]

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

Hi all,

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

  samples/sockmap/Makefile

between commit:

  4dfe1bb95235 ("bpf: sockmap sample use clang flag, -target bpf")

from the bpf tree and commit:

  2e04eb1dd1ca ("bpf: sockmap, remove samples program")

from the bpf-next tree.

I fixed it up (I just removed the file) 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

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

[Daniel Borkmann]

On 04/26/2018 02:53 AM, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the bpf-next tree got a conflict in:
> 
>   samples/sockmap/Makefile
> 
> between commit:
> 
>   4dfe1bb95235 ("bpf: sockmap sample use clang flag, -target bpf")
> 
> from the bpf tree and commit:
> 
>   2e04eb1dd1ca ("bpf: sockmap, remove samples program")
> 
> from the bpf-next tree.
> 
> I fixed it up (I just removed the file) 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.

That's correct as well, thank you!

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

[Stephen Rothwell]

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

Hi all,

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

  tools/testing/selftests/bpf/test_verifier.c

between commit:

  ca36960211eb ("bpf: allow xadd only on aligned memory")

from the bpf tree and commit:

  23d191a82c13 ("bpf: add various jit test cases")

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/test_verifier.c
index 437c0b1c9d21,c987d3a2426f..000000000000
--- a/tools/testing/selftests/bpf/test_verifier.c
+++ b/tools/testing/selftests/bpf/test_verifier.c
@@@ -11163,64 -11140,95 +11166,153 @@@ static struct bpf_test tests[] = 
  		.result = REJECT,
  		.prog_type = BPF_PROG_TYPE_TRACEPOINT,
  	},
 +	{
 +		"xadd/w check unaligned stack",
 +		.insns = {
 +			BPF_MOV64_IMM(BPF_REG_0, 1),
 +			BPF_STX_MEM(BPF_DW, BPF_REG_10, BPF_REG_0, -8),
 +			BPF_STX_XADD(BPF_W, BPF_REG_10, BPF_REG_0, -7),
 +			BPF_LDX_MEM(BPF_DW, BPF_REG_0, BPF_REG_10, -8),
 +			BPF_EXIT_INSN(),
 +		},
 +		.result = REJECT,
 +		.errstr = "misaligned stack access off",
 +		.prog_type = BPF_PROG_TYPE_SCHED_CLS,
 +	},
 +	{
 +		"xadd/w check unaligned map",
 +		.insns = {
 +			BPF_ST_MEM(BPF_DW, BPF_REG_10, -8, 0),
 +			BPF_MOV64_REG(BPF_REG_2, BPF_REG_10),
 +			BPF_ALU64_IMM(BPF_ADD, BPF_REG_2, -8),
 +			BPF_LD_MAP_FD(BPF_REG_1, 0),
 +			BPF_RAW_INSN(BPF_JMP | BPF_CALL, 0, 0, 0,
 +				     BPF_FUNC_map_lookup_elem),
 +			BPF_JMP_IMM(BPF_JNE, BPF_REG_0, 0, 1),
 +			BPF_EXIT_INSN(),
 +			BPF_MOV64_IMM(BPF_REG_1, 1),
 +			BPF_STX_XADD(BPF_W, BPF_REG_0, BPF_REG_1, 3),
 +			BPF_LDX_MEM(BPF_W, BPF_REG_0, BPF_REG_0, 3),
 +			BPF_EXIT_INSN(),
 +		},
 +		.fixup_map1 = { 3 },
 +		.result = REJECT,
 +		.errstr = "misaligned value access off",
 +		.prog_type = BPF_PROG_TYPE_SCHED_CLS,
 +	},
 +	{
 +		"xadd/w check unaligned pkt",
 +		.insns = {
 +			BPF_LDX_MEM(BPF_W, BPF_REG_2, BPF_REG_1,
 +				    offsetof(struct xdp_md, data)),
 +			BPF_LDX_MEM(BPF_W, BPF_REG_3, BPF_REG_1,
 +				    offsetof(struct xdp_md, data_end)),
 +			BPF_MOV64_REG(BPF_REG_1, BPF_REG_2),
 +			BPF_ALU64_IMM(BPF_ADD, BPF_REG_1, 8),
 +			BPF_JMP_REG(BPF_JLT, BPF_REG_1, BPF_REG_3, 2),
 +			BPF_MOV64_IMM(BPF_REG_0, 99),
 +			BPF_JMP_IMM(BPF_JA, 0, 0, 6),
 +			BPF_MOV64_IMM(BPF_REG_0, 1),
 +			BPF_ST_MEM(BPF_W, BPF_REG_2, 0, 0),
 +			BPF_ST_MEM(BPF_W, BPF_REG_2, 3, 0),
 +			BPF_STX_XADD(BPF_W, BPF_REG_2, BPF_REG_0, 1),
 +			BPF_STX_XADD(BPF_W, BPF_REG_2, BPF_REG_0, 2),
 +			BPF_LDX_MEM(BPF_W, BPF_REG_0, BPF_REG_2, 1),
 +			BPF_EXIT_INSN(),
 +		},
 +		.result = REJECT,
 +		.errstr = "BPF_XADD stores into R2 packet",
 +		.prog_type = BPF_PROG_TYPE_XDP,
 +	},
+ 	{
+ 		"jit: lsh, rsh, arsh by 1",
+ 		.insns = {
+ 			BPF_MOV64_IMM(BPF_REG_0, 1),
+ 			BPF_MOV64_IMM(BPF_REG_1, 0xff),
+ 			BPF_ALU64_IMM(BPF_LSH, BPF_REG_1, 1),
+ 			BPF_ALU32_IMM(BPF_LSH, BPF_REG_1, 1),
+ 			BPF_JMP_IMM(BPF_JEQ, BPF_REG_1, 0x3fc, 1),
+ 			BPF_EXIT_INSN(),
+ 			BPF_ALU64_IMM(BPF_RSH, BPF_REG_1, 1),
+ 			BPF_ALU32_IMM(BPF_RSH, BPF_REG_1, 1),
+ 			BPF_JMP_IMM(BPF_JEQ, BPF_REG_1, 0xff, 1),
+ 			BPF_EXIT_INSN(),
+ 			BPF_ALU64_IMM(BPF_ARSH, BPF_REG_1, 1),
+ 			BPF_JMP_IMM(BPF_JEQ, BPF_REG_1, 0x7f, 1),
+ 			BPF_EXIT_INSN(),
+ 			BPF_MOV64_IMM(BPF_REG_0, 2),
+ 			BPF_EXIT_INSN(),
+ 		},
+ 		.result = ACCEPT,
+ 		.retval = 2,
+ 	},
+ 	{
+ 		"jit: mov32 for ldimm64, 1",
+ 		.insns = {
+ 			BPF_MOV64_IMM(BPF_REG_0, 2),
+ 			BPF_LD_IMM64(BPF_REG_1, 0xfeffffffffffffffULL),
+ 			BPF_ALU64_IMM(BPF_RSH, BPF_REG_1, 32),
+ 			BPF_LD_IMM64(BPF_REG_2, 0xfeffffffULL),
+ 			BPF_JMP_REG(BPF_JEQ, BPF_REG_1, BPF_REG_2, 1),
+ 			BPF_MOV64_IMM(BPF_REG_0, 1),
+ 			BPF_EXIT_INSN(),
+ 		},
+ 		.result = ACCEPT,
+ 		.retval = 2,
+ 	},
+ 	{
+ 		"jit: mov32 for ldimm64, 2",
+ 		.insns = {
+ 			BPF_MOV64_IMM(BPF_REG_0, 1),
+ 			BPF_LD_IMM64(BPF_REG_1, 0x1ffffffffULL),
+ 			BPF_LD_IMM64(BPF_REG_2, 0xffffffffULL),
+ 			BPF_JMP_REG(BPF_JEQ, BPF_REG_1, BPF_REG_2, 1),
+ 			BPF_MOV64_IMM(BPF_REG_0, 2),
+ 			BPF_EXIT_INSN(),
+ 		},
+ 		.result = ACCEPT,
+ 		.retval = 2,
+ 	},
+ 	{
+ 		"jit: various mul tests",
+ 		.insns = {
+ 			BPF_LD_IMM64(BPF_REG_2, 0xeeff0d413122ULL),
+ 			BPF_LD_IMM64(BPF_REG_0, 0xfefefeULL),
+ 			BPF_LD_IMM64(BPF_REG_1, 0xefefefULL),
+ 			BPF_ALU64_REG(BPF_MUL, BPF_REG_0, BPF_REG_1),
+ 			BPF_JMP_REG(BPF_JEQ, BPF_REG_0, BPF_REG_2, 2),
+ 			BPF_MOV64_IMM(BPF_REG_0, 1),
+ 			BPF_EXIT_INSN(),
+ 			BPF_LD_IMM64(BPF_REG_3, 0xfefefeULL),
+ 			BPF_ALU64_REG(BPF_MUL, BPF_REG_3, BPF_REG_1),
+ 			BPF_JMP_REG(BPF_JEQ, BPF_REG_3, BPF_REG_2, 2),
+ 			BPF_MOV64_IMM(BPF_REG_0, 1),
+ 			BPF_EXIT_INSN(),
+ 			BPF_MOV32_REG(BPF_REG_2, BPF_REG_2),
+ 			BPF_LD_IMM64(BPF_REG_0, 0xfefefeULL),
+ 			BPF_ALU32_REG(BPF_MUL, BPF_REG_0, BPF_REG_1),
+ 			BPF_JMP_REG(BPF_JEQ, BPF_REG_0, BPF_REG_2, 2),
+ 			BPF_MOV64_IMM(BPF_REG_0, 1),
+ 			BPF_EXIT_INSN(),
+ 			BPF_LD_IMM64(BPF_REG_3, 0xfefefeULL),
+ 			BPF_ALU32_REG(BPF_MUL, BPF_REG_3, BPF_REG_1),
+ 			BPF_JMP_REG(BPF_JEQ, BPF_REG_3, BPF_REG_2, 2),
+ 			BPF_MOV64_IMM(BPF_REG_0, 1),
+ 			BPF_EXIT_INSN(),
+ 			BPF_LD_IMM64(BPF_REG_0, 0x952a7bbcULL),
+ 			BPF_LD_IMM64(BPF_REG_1, 0xfefefeULL),
+ 			BPF_LD_IMM64(BPF_REG_2, 0xeeff0d413122ULL),
+ 			BPF_ALU32_REG(BPF_MUL, BPF_REG_2, BPF_REG_1),
+ 			BPF_JMP_REG(BPF_JEQ, BPF_REG_2, BPF_REG_0, 2),
+ 			BPF_MOV64_IMM(BPF_REG_0, 1),
+ 			BPF_EXIT_INSN(),
+ 			BPF_MOV64_IMM(BPF_REG_0, 2),
+ 			BPF_EXIT_INSN(),
+ 		},
+ 		.result = ACCEPT,
+ 		.retval = 2,
+ 	},
+ 
  };
  
  static int probe_filter_length(const struct bpf_insn *fp)

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

[Daniel Borkmann]

On 02/26/2018 01:41 AM, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the bpf-next tree got a conflict in:
> 
>   tools/testing/selftests/bpf/test_verifier.c
> 
> between commit:
> 
>   ca36960211eb ("bpf: allow xadd only on aligned memory")
> 
> from the bpf tree and commit:
> 
>   23d191a82c13 ("bpf: add various jit test cases")
> 
> 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.

Looks good, thanks!

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

[Stephen Rothwell]

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

Hi Dave,

On Mon, 26 Feb 2018 11:41:47 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Today's linux-next merge of the bpf-next tree got a conflict in:
> 
>   tools/testing/selftests/bpf/test_verifier.c
> 
> between commit:
> 
>   ca36960211eb ("bpf: allow xadd only on aligned memory")
> 
> from the bpf tree and commit:
> 
>   23d191a82c13 ("bpf: add various jit test cases")
> 
> 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/test_verifier.c
> index 437c0b1c9d21,c987d3a2426f..000000000000
> --- a/tools/testing/selftests/bpf/test_verifier.c
> +++ b/tools/testing/selftests/bpf/test_verifier.c
> @@@ -11163,64 -11140,95 +11166,153 @@@ static struct bpf_test tests[] = 
>   		.result = REJECT,
>   		.prog_type = BPF_PROG_TYPE_TRACEPOINT,
>   	},
>  +	{
>  +		"xadd/w check unaligned stack",
>  +		.insns = {
>  +			BPF_MOV64_IMM(BPF_REG_0, 1),
>  +			BPF_STX_MEM(BPF_DW, BPF_REG_10, BPF_REG_0, -8),
>  +			BPF_STX_XADD(BPF_W, BPF_REG_10, BPF_REG_0, -7),
>  +			BPF_LDX_MEM(BPF_DW, BPF_REG_0, BPF_REG_10, -8),
>  +			BPF_EXIT_INSN(),
>  +		},
>  +		.result = REJECT,
>  +		.errstr = "misaligned stack access off",
>  +		.prog_type = BPF_PROG_TYPE_SCHED_CLS,
>  +	},
>  +	{
>  +		"xadd/w check unaligned map",
>  +		.insns = {
>  +			BPF_ST_MEM(BPF_DW, BPF_REG_10, -8, 0),
>  +			BPF_MOV64_REG(BPF_REG_2, BPF_REG_10),
>  +			BPF_ALU64_IMM(BPF_ADD, BPF_REG_2, -8),
>  +			BPF_LD_MAP_FD(BPF_REG_1, 0),
>  +			BPF_RAW_INSN(BPF_JMP | BPF_CALL, 0, 0, 0,
>  +				     BPF_FUNC_map_lookup_elem),
>  +			BPF_JMP_IMM(BPF_JNE, BPF_REG_0, 0, 1),
>  +			BPF_EXIT_INSN(),
>  +			BPF_MOV64_IMM(BPF_REG_1, 1),
>  +			BPF_STX_XADD(BPF_W, BPF_REG_0, BPF_REG_1, 3),
>  +			BPF_LDX_MEM(BPF_W, BPF_REG_0, BPF_REG_0, 3),
>  +			BPF_EXIT_INSN(),
>  +		},
>  +		.fixup_map1 = { 3 },
>  +		.result = REJECT,
>  +		.errstr = "misaligned value access off",
>  +		.prog_type = BPF_PROG_TYPE_SCHED_CLS,
>  +	},
>  +	{
>  +		"xadd/w check unaligned pkt",
>  +		.insns = {
>  +			BPF_LDX_MEM(BPF_W, BPF_REG_2, BPF_REG_1,
>  +				    offsetof(struct xdp_md, data)),
>  +			BPF_LDX_MEM(BPF_W, BPF_REG_3, BPF_REG_1,
>  +				    offsetof(struct xdp_md, data_end)),
>  +			BPF_MOV64_REG(BPF_REG_1, BPF_REG_2),
>  +			BPF_ALU64_IMM(BPF_ADD, BPF_REG_1, 8),
>  +			BPF_JMP_REG(BPF_JLT, BPF_REG_1, BPF_REG_3, 2),
>  +			BPF_MOV64_IMM(BPF_REG_0, 99),
>  +			BPF_JMP_IMM(BPF_JA, 0, 0, 6),
>  +			BPF_MOV64_IMM(BPF_REG_0, 1),
>  +			BPF_ST_MEM(BPF_W, BPF_REG_2, 0, 0),
>  +			BPF_ST_MEM(BPF_W, BPF_REG_2, 3, 0),
>  +			BPF_STX_XADD(BPF_W, BPF_REG_2, BPF_REG_0, 1),
>  +			BPF_STX_XADD(BPF_W, BPF_REG_2, BPF_REG_0, 2),
>  +			BPF_LDX_MEM(BPF_W, BPF_REG_0, BPF_REG_2, 1),
>  +			BPF_EXIT_INSN(),
>  +		},
>  +		.result = REJECT,
>  +		.errstr = "BPF_XADD stores into R2 packet",
>  +		.prog_type = BPF_PROG_TYPE_XDP,
>  +	},
> + 	{
> + 		"jit: lsh, rsh, arsh by 1",
> + 		.insns = {
> + 			BPF_MOV64_IMM(BPF_REG_0, 1),
> + 			BPF_MOV64_IMM(BPF_REG_1, 0xff),
> + 			BPF_ALU64_IMM(BPF_LSH, BPF_REG_1, 1),
> + 			BPF_ALU32_IMM(BPF_LSH, BPF_REG_1, 1),
> + 			BPF_JMP_IMM(BPF_JEQ, BPF_REG_1, 0x3fc, 1),
> + 			BPF_EXIT_INSN(),
> + 			BPF_ALU64_IMM(BPF_RSH, BPF_REG_1, 1),
> + 			BPF_ALU32_IMM(BPF_RSH, BPF_REG_1, 1),
> + 			BPF_JMP_IMM(BPF_JEQ, BPF_REG_1, 0xff, 1),
> + 			BPF_EXIT_INSN(),
> + 			BPF_ALU64_IMM(BPF_ARSH, BPF_REG_1, 1),
> + 			BPF_JMP_IMM(BPF_JEQ, BPF_REG_1, 0x7f, 1),
> + 			BPF_EXIT_INSN(),
> + 			BPF_MOV64_IMM(BPF_REG_0, 2),
> + 			BPF_EXIT_INSN(),
> + 		},
> + 		.result = ACCEPT,
> + 		.retval = 2,
> + 	},
> + 	{
> + 		"jit: mov32 for ldimm64, 1",
> + 		.insns = {
> + 			BPF_MOV64_IMM(BPF_REG_0, 2),
> + 			BPF_LD_IMM64(BPF_REG_1, 0xfeffffffffffffffULL),
> + 			BPF_ALU64_IMM(BPF_RSH, BPF_REG_1, 32),
> + 			BPF_LD_IMM64(BPF_REG_2, 0xfeffffffULL),
> + 			BPF_JMP_REG(BPF_JEQ, BPF_REG_1, BPF_REG_2, 1),
> + 			BPF_MOV64_IMM(BPF_REG_0, 1),
> + 			BPF_EXIT_INSN(),
> + 		},
> + 		.result = ACCEPT,
> + 		.retval = 2,
> + 	},
> + 	{
> + 		"jit: mov32 for ldimm64, 2",
> + 		.insns = {
> + 			BPF_MOV64_IMM(BPF_REG_0, 1),
> + 			BPF_LD_IMM64(BPF_REG_1, 0x1ffffffffULL),
> + 			BPF_LD_IMM64(BPF_REG_2, 0xffffffffULL),
> + 			BPF_JMP_REG(BPF_JEQ, BPF_REG_1, BPF_REG_2, 1),
> + 			BPF_MOV64_IMM(BPF_REG_0, 2),
> + 			BPF_EXIT_INSN(),
> + 		},
> + 		.result = ACCEPT,
> + 		.retval = 2,
> + 	},
> + 	{
> + 		"jit: various mul tests",
> + 		.insns = {
> + 			BPF_LD_IMM64(BPF_REG_2, 0xeeff0d413122ULL),
> + 			BPF_LD_IMM64(BPF_REG_0, 0xfefefeULL),
> + 			BPF_LD_IMM64(BPF_REG_1, 0xefefefULL),
> + 			BPF_ALU64_REG(BPF_MUL, BPF_REG_0, BPF_REG_1),
> + 			BPF_JMP_REG(BPF_JEQ, BPF_REG_0, BPF_REG_2, 2),
> + 			BPF_MOV64_IMM(BPF_REG_0, 1),
> + 			BPF_EXIT_INSN(),
> + 			BPF_LD_IMM64(BPF_REG_3, 0xfefefeULL),
> + 			BPF_ALU64_REG(BPF_MUL, BPF_REG_3, BPF_REG_1),
> + 			BPF_JMP_REG(BPF_JEQ, BPF_REG_3, BPF_REG_2, 2),
> + 			BPF_MOV64_IMM(BPF_REG_0, 1),
> + 			BPF_EXIT_INSN(),
> + 			BPF_MOV32_REG(BPF_REG_2, BPF_REG_2),
> + 			BPF_LD_IMM64(BPF_REG_0, 0xfefefeULL),
> + 			BPF_ALU32_REG(BPF_MUL, BPF_REG_0, BPF_REG_1),
> + 			BPF_JMP_REG(BPF_JEQ, BPF_REG_0, BPF_REG_2, 2),
> + 			BPF_MOV64_IMM(BPF_REG_0, 1),
> + 			BPF_EXIT_INSN(),
> + 			BPF_LD_IMM64(BPF_REG_3, 0xfefefeULL),
> + 			BPF_ALU32_REG(BPF_MUL, BPF_REG_3, BPF_REG_1),
> + 			BPF_JMP_REG(BPF_JEQ, BPF_REG_3, BPF_REG_2, 2),
> + 			BPF_MOV64_IMM(BPF_REG_0, 1),
> + 			BPF_EXIT_INSN(),
> + 			BPF_LD_IMM64(BPF_REG_0, 0x952a7bbcULL),
> + 			BPF_LD_IMM64(BPF_REG_1, 0xfefefeULL),
> + 			BPF_LD_IMM64(BPF_REG_2, 0xeeff0d413122ULL),
> + 			BPF_ALU32_REG(BPF_MUL, BPF_REG_2, BPF_REG_1),
> + 			BPF_JMP_REG(BPF_JEQ, BPF_REG_2, BPF_REG_0, 2),
> + 			BPF_MOV64_IMM(BPF_REG_0, 1),
> + 			BPF_EXIT_INSN(),
> + 			BPF_MOV64_IMM(BPF_REG_0, 2),
> + 			BPF_EXIT_INSN(),
> + 		},
> + 		.result = ACCEPT,
> + 		.retval = 2,
> + 	},
> + 
>   };
>   
>   static int probe_filter_length(const struct bpf_insn *fp)

This conflict is now between the bfp tree and the net-next tree.

-- 
Cheers,
Stephen Rothwell

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