bpf.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Daniel Borkmann <daniel@iogearbox.net>
To: bpf@vger.kernel.org
Cc: ast@kernel.org, joe@wand.net.nz, yhs@fb.com,
	andrii.nakryiko@gmail.com, kafai@fb.com,
	Daniel Borkmann <daniel@iogearbox.net>
Subject: [PATCH bpf-next v3 07/15] bpf: allow for key-less BTF in array map
Date: Wed,  3 Apr 2019 20:22:58 +0200	[thread overview]
Message-ID: <2ee9fa3052abb17dde737add2726c86b5e18385b.1554314902.git.daniel@iogearbox.net> (raw)
In-Reply-To: <cover.1554314902.git.daniel@iogearbox.net>
In-Reply-To: <cover.1554314902.git.daniel@iogearbox.net>

Given we'll be reusing BPF array maps for global data/bss/rodata
sections, we need a way to associate BTF DataSec type as its map
value type. In usual cases we have this ugly BPF_ANNOTATE_KV_PAIR()
macro hack e.g. via 38d5d3b3d5db ("bpf: Introduce BPF_ANNOTATE_KV_PAIR")
to get initial map to type association going. While more use cases
for it are discouraged, this also won't work for global data since
the use of array map is a BPF loader detail and therefore unknown
at compilation time. For array maps with just a single entry we make
an exception in terms of BTF in that key type is declared optional
if value type is of DataSec type. Latter LLVM is guaranteed to emit
and it also aligns with how we regard global data maps as just a
plain buffer area reusing existing map facilities for allowing things
like introspection with existing tools.

Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
---
 include/linux/btf.h        |  2 ++
 kernel/bpf/arraymap.c      | 15 ++++++++++++++-
 kernel/bpf/btf.c           |  7 ++++++-
 kernel/bpf/local_storage.c |  2 ++
 kernel/bpf/lpm_trie.c      |  3 +++
 kernel/bpf/syscall.c       | 15 +++++++++++----
 6 files changed, 38 insertions(+), 6 deletions(-)

diff --git a/include/linux/btf.h b/include/linux/btf.h
index 455d31b..747ac99 100644
--- a/include/linux/btf.h
+++ b/include/linux/btf.h
@@ -51,6 +51,8 @@ bool btf_member_is_reg_int(const struct btf *btf, const struct btf_type *s,
 			   const struct btf_member *m,
 			   u32 expected_offset, u32 expected_size);
 int btf_find_spin_lock(const struct btf *btf, const struct btf_type *t);
+const struct btf_type *btf_type_void_get(void);
+bool btf_type_is_void(const struct btf_type *t);
 
 #ifdef CONFIG_BPF_SYSCALL
 const struct btf_type *btf_type_by_id(const struct btf *btf, u32 type_id);
diff --git a/kernel/bpf/arraymap.c b/kernel/bpf/arraymap.c
index 411626f..282ddce 100644
--- a/kernel/bpf/arraymap.c
+++ b/kernel/bpf/arraymap.c
@@ -388,7 +388,8 @@ static void array_map_seq_show_elem(struct bpf_map *map, void *key,
 		return;
 	}
 
-	seq_printf(m, "%u: ", *(u32 *)key);
+	if (map->btf_key_type_id)
+		seq_printf(m, "%u: ", *(u32 *)key);
 	btf_type_seq_show(map->btf, map->btf_value_type_id, value, m);
 	seq_puts(m, "\n");
 
@@ -425,6 +426,18 @@ static int array_map_check_btf(const struct bpf_map *map,
 {
 	u32 int_data;
 
+	/* One exception for keyless BTF: .bss/.data/.rodata map */
+	if (btf_type_is_void(key_type)) {
+		if (map->map_type != BPF_MAP_TYPE_ARRAY ||
+		    map->max_entries != 1)
+			return -EINVAL;
+
+		if (BTF_INFO_KIND(value_type->info) != BTF_KIND_DATASEC)
+			return -EINVAL;
+
+		return 0;
+	}
+
 	if (BTF_INFO_KIND(key_type->info) != BTF_KIND_INT)
 		return -EINVAL;
 
diff --git a/kernel/bpf/btf.c b/kernel/bpf/btf.c
index 5c9285c..85aab99 100644
--- a/kernel/bpf/btf.c
+++ b/kernel/bpf/btf.c
@@ -327,7 +327,12 @@ static bool btf_type_is_modifier(const struct btf_type *t)
 	return false;
 }
 
-static bool btf_type_is_void(const struct btf_type *t)
+const struct btf_type *btf_type_void_get(void)
+{
+	return &btf_void;
+}
+
+bool btf_type_is_void(const struct btf_type *t)
 {
 	return t == &btf_void;
 }
diff --git a/kernel/bpf/local_storage.c b/kernel/bpf/local_storage.c
index 980e8f1..5e3a0f8 100644
--- a/kernel/bpf/local_storage.c
+++ b/kernel/bpf/local_storage.c
@@ -338,6 +338,8 @@ static int cgroup_storage_check_btf(const struct bpf_map *map,
 	 *	__u32	attach_type;
 	 * };
 	 */
+	if (btf_type_is_void(key_type))
+		return -EINVAL;
 
 	/*
 	 * Key_type must be a structure with two fields.
diff --git a/kernel/bpf/lpm_trie.c b/kernel/bpf/lpm_trie.c
index e61630c..182378f 100644
--- a/kernel/bpf/lpm_trie.c
+++ b/kernel/bpf/lpm_trie.c
@@ -734,6 +734,9 @@ static int trie_check_btf(const struct bpf_map *map,
 			  const struct btf_type *key_type,
 			  const struct btf_type *value_type)
 {
+	if (btf_type_is_void(key_type))
+		return -EINVAL;
+
 	/* Keys must have struct bpf_lpm_trie_key embedded. */
 	return BTF_INFO_KIND(key_type->info) != BTF_KIND_STRUCT ?
 	       -EINVAL : 0;
diff --git a/kernel/bpf/syscall.c b/kernel/bpf/syscall.c
index dcff630..c4c9efa 100644
--- a/kernel/bpf/syscall.c
+++ b/kernel/bpf/syscall.c
@@ -494,9 +494,16 @@ static int map_check_btf(struct bpf_map *map, const struct btf *btf,
 	u32 key_size, value_size;
 	int ret = 0;
 
-	key_type = btf_type_id_size(btf, &btf_key_id, &key_size);
-	if (!key_type || key_size != map->key_size)
-		return -EINVAL;
+	/* Some maps allow key to be unspecified. */
+	if (btf_key_id) {
+		key_type = btf_type_id_size(btf, &btf_key_id, &key_size);
+		if (!key_type || key_size != map->key_size)
+			return -EINVAL;
+	} else {
+		key_type = btf_type_void_get();
+		if (!map->ops->map_check_btf)
+			return -EINVAL;
+	}
 
 	value_type = btf_type_id_size(btf, &btf_value_id, &value_size);
 	if (!value_type || value_size != map->value_size)
@@ -564,7 +571,7 @@ static int map_create(union bpf_attr *attr)
 	if (attr->btf_key_type_id || attr->btf_value_type_id) {
 		struct btf *btf;
 
-		if (!attr->btf_key_type_id || !attr->btf_value_type_id) {
+		if (!attr->btf_value_type_id) {
 			err = -EINVAL;
 			goto free_map_nouncharge;
 		}
-- 
2.9.5


  parent reply	other threads:[~2019-04-03 18:23 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-03 18:22 [PATCH bpf-next v3 00/15] BPF support for global data Daniel Borkmann
2019-04-03 18:22 ` [PATCH bpf-next v3 01/15] bpf: implement lookup-free direct value access for maps Daniel Borkmann
2019-04-03 18:22 ` [PATCH bpf-next v3 02/15] bpf: add program side {rd,wr}only support " Daniel Borkmann
2019-04-03 18:22 ` [PATCH bpf-next v3 03/15] bpf: add syscall side map lock support Daniel Borkmann
2019-04-03 18:22 ` [PATCH bpf-next v3 04/15] bpf: allow . char as part of the object name Daniel Borkmann
2019-04-03 18:22 ` [PATCH bpf-next v3 05/15] bpf: add specification for BTF Var and DataSec kinds Daniel Borkmann
2019-04-03 18:22 ` [PATCH bpf-next v3 06/15] bpf: kernel side support for BTF Var and DataSec Daniel Borkmann
2019-04-04 19:20   ` Martin Lau
2019-04-05  7:03     ` Martin Lau
2019-04-05  7:44       ` Daniel Borkmann
2019-04-03 18:22 ` Daniel Borkmann [this message]
2019-04-03 18:22 ` [PATCH bpf-next v3 08/15] bpf: sync {btf,bpf}.h uapi header from tools infrastructure Daniel Borkmann
2019-04-03 18:23 ` [PATCH bpf-next v3 09/15] bpf, libbpf: refactor relocation handling Daniel Borkmann
2019-04-03 18:23 ` [PATCH bpf-next v3 10/15] bpf, libbpf: support global data/bss/rodata sections Daniel Borkmann
2019-04-03 18:23 ` [PATCH bpf-next v3 11/15] bpf, libbpf: add support for BTF Var and DataSec Daniel Borkmann
2019-04-03 18:23 ` [PATCH bpf-next v3 12/15] bpf: bpftool support for dumping data/bss/rodata sections Daniel Borkmann
2019-04-03 18:23 ` [PATCH bpf-next v3 13/15] bpf, selftest: test {rd,wr}only flags and direct value access Daniel Borkmann
2019-04-03 18:23 ` [PATCH bpf-next v3 14/15] bpf, selftest: test global data/bss/rodata sections Daniel Borkmann
2019-04-03 18:23 ` [PATCH bpf-next v3 15/15] bpf, selftest: add test cases for BTF Var and DataSec Daniel Borkmann

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2ee9fa3052abb17dde737add2726c86b5e18385b.1554314902.git.daniel@iogearbox.net \
    --to=daniel@iogearbox.net \
    --cc=andrii.nakryiko@gmail.com \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=joe@wand.net.nz \
    --cc=kafai@fb.com \
    --cc=yhs@fb.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).