linux-next.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* linux-next: manual merge of the bpf-next tree with the bpf tree
@ 2020-05-15  3:18 Stephen Rothwell
  0 siblings, 0 replies; 27+ messages in thread
From: Stephen Rothwell @ 2020-05-15  3:18 UTC (permalink / raw)
  To: Daniel Borkmann, Alexei Starovoitov, Networking
  Cc: Linux Next Mailing List, Linux Kernel Mailing List, Yonghong Song

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

^ permalink raw reply	[flat|nested] 27+ messages in thread

* linux-next: manual merge of the bpf-next tree with the bpf tree
@ 2021-12-05 23:39 Stephen Rothwell
  0 siblings, 0 replies; 27+ messages in thread
From: Stephen Rothwell @ 2021-12-05 23:39 UTC (permalink / raw)
  To: Daniel Borkmann, Alexei Starovoitov, Andrii Nakryiko, bpf, Networking
  Cc: Kumar Kartikeya Dwivedi, Linux Kernel Mailing List,
	Linux Next Mailing List

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

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: linux-next: manual merge of the bpf-next tree with the bpf tree
  2020-09-30  4:07 Stephen Rothwell
@ 2020-10-02  3:59 ` Stephen Rothwell
  0 siblings, 0 replies; 27+ messages in thread
From: Stephen Rothwell @ 2020-10-02  3:59 UTC (permalink / raw)
  To: Networking, David Miller
  Cc: Daniel Borkmann, Alexei Starovoitov, Andrii Nakryiko,
	Tony Ambardar, Linux Next Mailing List,
	Linux Kernel Mailing List

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

^ permalink raw reply	[flat|nested] 27+ messages in thread

* linux-next: manual merge of the bpf-next tree with the bpf tree
@ 2020-09-30  4:07 Stephen Rothwell
  2020-10-02  3:59 ` Stephen Rothwell
  0 siblings, 1 reply; 27+ messages in thread
From: Stephen Rothwell @ 2020-09-30  4:07 UTC (permalink / raw)
  To: Daniel Borkmann, Alexei Starovoitov, Networking
  Cc: Andrii Nakryiko, Tony Ambardar, Linux Next Mailing List,
	Linux Kernel Mailing List

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

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: linux-next: manual merge of the bpf-next tree with the bpf tree
  2020-06-26  0:05 Stephen Rothwell
@ 2020-07-06  1:43 ` Stephen Rothwell
  0 siblings, 0 replies; 27+ messages in thread
From: Stephen Rothwell @ 2020-07-06  1:43 UTC (permalink / raw)
  To: Daniel Borkmann, Alexei Starovoitov, Networking, David Miller
  Cc: Linux Next Mailing List, Linux Kernel Mailing List,
	Yonghong Song, Andrii Nakryiko

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

^ permalink raw reply	[flat|nested] 27+ messages in thread

* linux-next: manual merge of the bpf-next tree with the bpf tree
@ 2020-06-26  0:05 Stephen Rothwell
  2020-07-06  1:43 ` Stephen Rothwell
  0 siblings, 1 reply; 27+ messages in thread
From: Stephen Rothwell @ 2020-06-26  0:05 UTC (permalink / raw)
  To: Daniel Borkmann, Alexei Starovoitov, Networking
  Cc: Linux Next Mailing List, Linux Kernel Mailing List,
	Yonghong Song, Andrii Nakryiko

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

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: linux-next: manual merge of the bpf-next tree with the bpf tree
  2019-10-08 22:47 Stephen Rothwell
@ 2019-10-15 23:29 ` Stephen Rothwell
  0 siblings, 0 replies; 27+ messages in thread
From: Stephen Rothwell @ 2019-10-15 23:29 UTC (permalink / raw)
  To: David Miller
  Cc: Daniel Borkmann, Alexei Starovoitov, Networking,
	Linux Next Mailing List, Linux Kernel Mailing List,
	Andrii Nakryiko, Yonghong Song

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

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: linux-next: manual merge of the bpf-next tree with the bpf tree
  2019-10-07 22:48 Stephen Rothwell
@ 2019-10-15 23:27 ` Stephen Rothwell
  0 siblings, 0 replies; 27+ messages in thread
From: Stephen Rothwell @ 2019-10-15 23:27 UTC (permalink / raw)
  To: David Miller
  Cc: Daniel Borkmann, Alexei Starovoitov, Networking,
	Linux Next Mailing List, Linux Kernel Mailing List,
	Yonghong Song, Toke Høiland-Jørgensen

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

^ permalink raw reply	[flat|nested] 27+ messages in thread

* linux-next: manual merge of the bpf-next tree with the bpf tree
@ 2019-10-08 22:47 Stephen Rothwell
  2019-10-15 23:29 ` Stephen Rothwell
  0 siblings, 1 reply; 27+ messages in thread
From: Stephen Rothwell @ 2019-10-08 22:47 UTC (permalink / raw)
  To: Daniel Borkmann, Alexei Starovoitov, Networking
  Cc: Linux Next Mailing List, Linux Kernel Mailing List,
	Andrii Nakryiko, Yonghong Song

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

^ permalink raw reply	[flat|nested] 27+ messages in thread

* linux-next: manual merge of the bpf-next tree with the bpf tree
@ 2019-10-07 22:48 Stephen Rothwell
  2019-10-15 23:27 ` Stephen Rothwell
  0 siblings, 1 reply; 27+ messages in thread
From: Stephen Rothwell @ 2019-10-07 22:48 UTC (permalink / raw)
  To: Daniel Borkmann, Alexei Starovoitov, Networking
  Cc: Linux Next Mailing List, Linux Kernel Mailing List,
	Yonghong Song, Toke Høiland-Jørgensen

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

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: linux-next: manual merge of the bpf-next tree with the bpf tree
  2019-04-17  1:08 Stephen Rothwell
@ 2019-04-24  3:12 ` Stephen Rothwell
  0 siblings, 0 replies; 27+ messages in thread
From: Stephen Rothwell @ 2019-04-24  3:12 UTC (permalink / raw)
  To: Daniel Borkmann, Alexei Starovoitov, Networking, David Miller
  Cc: Linux Next Mailing List, Linux Kernel Mailing List, Benjamin Poirier

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

^ permalink raw reply	[flat|nested] 27+ messages in thread

* linux-next: manual merge of the bpf-next tree with the bpf tree
@ 2019-04-17  1:08 Stephen Rothwell
  2019-04-24  3:12 ` Stephen Rothwell
  0 siblings, 1 reply; 27+ messages in thread
From: Stephen Rothwell @ 2019-04-17  1:08 UTC (permalink / raw)
  To: Daniel Borkmann, Alexei Starovoitov, Networking
  Cc: Linux Next Mailing List, Linux Kernel Mailing List, Benjamin Poirier

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

^ permalink raw reply	[flat|nested] 27+ messages in thread

* linux-next: manual merge of the bpf-next tree with the bpf tree
@ 2018-12-04  1:09 Stephen Rothwell
  0 siblings, 0 replies; 27+ messages in thread
From: Stephen Rothwell @ 2018-12-04  1:09 UTC (permalink / raw)
  To: Daniel Borkmann, Alexei Starovoitov, Networking
  Cc: Linux Next Mailing List, Linux Kernel Mailing List, Petar Penkov,
	Vlad Dumitrescu, Willem de Bruijn

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

^ permalink raw reply	[flat|nested] 27+ messages in thread

* linux-next: manual merge of the bpf-next tree with the bpf tree
@ 2018-12-04  1:05 Stephen Rothwell
  0 siblings, 0 replies; 27+ messages in thread
From: Stephen Rothwell @ 2018-12-04  1:05 UTC (permalink / raw)
  To: Daniel Borkmann, Alexei Starovoitov, Networking
  Cc: Linux Next Mailing List, Linux Kernel Mailing List,
	Quentin Monnet, Joe Stringer

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

^ permalink raw reply	[flat|nested] 27+ messages in thread

* linux-next: manual merge of the bpf-next tree with the bpf tree
@ 2018-11-12  0:54 Stephen Rothwell
  0 siblings, 0 replies; 27+ messages in thread
From: Stephen Rothwell @ 2018-11-12  0:54 UTC (permalink / raw)
  To: Daniel Borkmann, Alexei Starovoitov, Networking
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List,
	Andrey Ignatov, Nitin Hande

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

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: linux-next: manual merge of the bpf-next tree with the bpf tree
  2018-05-14 20:41 ` Jakub Kicinski
@ 2018-05-14 21:57   ` Stephen Rothwell
  0 siblings, 0 replies; 27+ messages in thread
From: Stephen Rothwell @ 2018-05-14 21:57 UTC (permalink / raw)
  To: Jakub Kicinski, Alexei Starovoitov
  Cc: Daniel Borkmann, Networking, Linux-Next Mailing List,
	Linux Kernel Mailing List

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

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: linux-next: manual merge of the bpf-next tree with the bpf tree
  2018-05-14  1:57 Stephen Rothwell
@ 2018-05-14 20:41 ` Jakub Kicinski
  2018-05-14 21:57   ` Stephen Rothwell
  0 siblings, 1 reply; 27+ messages in thread
From: Jakub Kicinski @ 2018-05-14 20:41 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Daniel Borkmann, Alexei Starovoitov, Networking,
	Linux-Next Mailing List, Linux Kernel Mailing List

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.

^ permalink raw reply	[flat|nested] 27+ messages in thread

* linux-next: manual merge of the bpf-next tree with the bpf tree
@ 2018-05-14  1:57 Stephen Rothwell
  2018-05-14 20:41 ` Jakub Kicinski
  0 siblings, 1 reply; 27+ messages in thread
From: Stephen Rothwell @ 2018-05-14  1:57 UTC (permalink / raw)
  To: Daniel Borkmann, Alexei Starovoitov, Networking
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Jakub Kicinski

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

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: linux-next: manual merge of the bpf-next tree with the bpf tree
  2018-05-02  5:50   ` Stephen Rothwell
@ 2018-05-02  6:05     ` Song Liu
  0 siblings, 0 replies; 27+ messages in thread
From: Song Liu @ 2018-05-02  6:05 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Daniel Borkmann, Alexei Starovoitov, Networking,
	Linux-Next Mailing List, Linux Kernel Mailing List,
	Yonghong Song



> 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

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: linux-next: manual merge of the bpf-next tree with the bpf tree
  2018-05-02  4:40 ` Song Liu
@ 2018-05-02  5:50   ` Stephen Rothwell
  2018-05-02  6:05     ` Song Liu
  0 siblings, 1 reply; 27+ messages in thread
From: Stephen Rothwell @ 2018-05-02  5:50 UTC (permalink / raw)
  To: Song Liu
  Cc: Daniel Borkmann, Alexei Starovoitov, Networking,
	Linux-Next Mailing List, Linux Kernel Mailing List,
	Yonghong Song

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

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: linux-next: manual merge of the bpf-next tree with the bpf tree
  2018-05-02  2:09 Stephen Rothwell
@ 2018-05-02  4:40 ` Song Liu
  2018-05-02  5:50   ` Stephen Rothwell
  0 siblings, 1 reply; 27+ messages in thread
From: Song Liu @ 2018-05-02  4:40 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Daniel Borkmann, Alexei Starovoitov, Networking,
	Linux-Next Mailing List, Linux Kernel Mailing List,
	Yonghong Song



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

^ permalink raw reply	[flat|nested] 27+ messages in thread

* linux-next: manual merge of the bpf-next tree with the bpf tree
@ 2018-05-02  2:09 Stephen Rothwell
  2018-05-02  4:40 ` Song Liu
  0 siblings, 1 reply; 27+ messages in thread
From: Stephen Rothwell @ 2018-05-02  2:09 UTC (permalink / raw)
  To: Daniel Borkmann, Alexei Starovoitov, Networking
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Song Liu,
	Yonghong Song

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

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: linux-next: manual merge of the bpf-next tree with the bpf tree
  2018-04-26  0:53 Stephen Rothwell
@ 2018-04-26  7:57 ` Daniel Borkmann
  0 siblings, 0 replies; 27+ messages in thread
From: Daniel Borkmann @ 2018-04-26  7:57 UTC (permalink / raw)
  To: Stephen Rothwell, Alexei Starovoitov, Networking
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List, John Fastabend

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!

^ permalink raw reply	[flat|nested] 27+ messages in thread

* linux-next: manual merge of the bpf-next tree with the bpf tree
@ 2018-04-26  0:53 Stephen Rothwell
  2018-04-26  7:57 ` Daniel Borkmann
  0 siblings, 1 reply; 27+ messages in thread
From: Stephen Rothwell @ 2018-04-26  0:53 UTC (permalink / raw)
  To: Daniel Borkmann, Alexei Starovoitov, Networking
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List, John Fastabend

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

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: linux-next: manual merge of the bpf-next tree with the bpf tree
  2018-02-26  0:41 Stephen Rothwell
  2018-02-26  9:03 ` Daniel Borkmann
@ 2018-02-26 23:28 ` Stephen Rothwell
  1 sibling, 0 replies; 27+ messages in thread
From: Stephen Rothwell @ 2018-02-26 23:28 UTC (permalink / raw)
  To: Networking, David Miller
  Cc: Daniel Borkmann, Alexei Starovoitov, Linux-Next Mailing List,
	Linux Kernel Mailing List

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

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: linux-next: manual merge of the bpf-next tree with the bpf tree
  2018-02-26  0:41 Stephen Rothwell
@ 2018-02-26  9:03 ` Daniel Borkmann
  2018-02-26 23:28 ` Stephen Rothwell
  1 sibling, 0 replies; 27+ messages in thread
From: Daniel Borkmann @ 2018-02-26  9:03 UTC (permalink / raw)
  To: Stephen Rothwell, Alexei Starovoitov, Networking
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List

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!

^ permalink raw reply	[flat|nested] 27+ messages in thread

* linux-next: manual merge of the bpf-next tree with the bpf tree
@ 2018-02-26  0:41 Stephen Rothwell
  2018-02-26  9:03 ` Daniel Borkmann
  2018-02-26 23:28 ` Stephen Rothwell
  0 siblings, 2 replies; 27+ messages in thread
From: Stephen Rothwell @ 2018-02-26  0:41 UTC (permalink / raw)
  To: Daniel Borkmann, Alexei Starovoitov, Networking
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List

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

^ permalink raw reply	[flat|nested] 27+ messages in thread

end of thread, other threads:[~2021-12-05 23:39 UTC | newest]

Thread overview: 27+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-05-15  3:18 linux-next: manual merge of the bpf-next tree with the bpf tree Stephen Rothwell
  -- strict thread matches above, loose matches on Subject: below --
2021-12-05 23:39 Stephen Rothwell
2020-09-30  4:07 Stephen Rothwell
2020-10-02  3:59 ` Stephen Rothwell
2020-06-26  0:05 Stephen Rothwell
2020-07-06  1:43 ` Stephen Rothwell
2019-10-08 22:47 Stephen Rothwell
2019-10-15 23:29 ` Stephen Rothwell
2019-10-07 22:48 Stephen Rothwell
2019-10-15 23:27 ` Stephen Rothwell
2019-04-17  1:08 Stephen Rothwell
2019-04-24  3:12 ` Stephen Rothwell
2018-12-04  1:09 Stephen Rothwell
2018-12-04  1:05 Stephen Rothwell
2018-11-12  0:54 Stephen Rothwell
2018-05-14  1:57 Stephen Rothwell
2018-05-14 20:41 ` Jakub Kicinski
2018-05-14 21:57   ` Stephen Rothwell
2018-05-02  2:09 Stephen Rothwell
2018-05-02  4:40 ` Song Liu
2018-05-02  5:50   ` Stephen Rothwell
2018-05-02  6:05     ` Song Liu
2018-04-26  0:53 Stephen Rothwell
2018-04-26  7:57 ` Daniel Borkmann
2018-02-26  0:41 Stephen Rothwell
2018-02-26  9:03 ` Daniel Borkmann
2018-02-26 23:28 ` Stephen Rothwell

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).