Introduce bpf ID
Subsystems (17)
v2 cover Introduce bpf ID
This patch series:
1) Introduce ID for both bpf_prog and bpf_map.
2) Add bpf commands to iterate the prog IDs and map IDs of the system.
3) Add bpf commands to get a prog/map fd from an ID
4) Add bpf command to get prog/map info from a fd. The prog/map info is a jump start in this patchset and it is not meant to be a complete list. They can be extended in the future patches.
v2:
Compiler warning fixes:
- Remove lockdep_is_held() usage. Add comment
to explain the lock situation instead.
- Add static for idr related variables
- Add __user to the uattr param in bpf_prog_get_info_by_fd() and bpf_map_get_info_by_fd().
Martin KaFai Lau (8):
bpf: Introduce bpf_prog ID
bpf: Introduce bpf_map ID
bpf: Add BPF_(PROG|MAP)_GET_NEXT_ID command
bpf: Add BPF_PROG_GET_FD_BY_ID
bpf: Add BPF_MAP_GET_FD_BY_ID
bpf: Add jited_len to struct bpf_prog
bpf: Add BPF_OBJ_GET_INFO_BY_FD
bpf: Test for bpf ID
arch/arm64/net/bpf_jit_comp.c | 1 + arch/powerpc/net/bpf_jit_comp64.c | 1 + arch/s390/net/bpf_jit_comp.c | 1 + arch/sparc/net/bpf_jit_comp_64.c | 1 + arch/x86/net/bpf_jit_comp.c | 1 + include/linux/bpf.h | 2 + include/linux/filter.h | 3 +- include/uapi/linux/bpf.h | 41 +++ kernel/bpf/syscall.c | 433 ++++++++++++++++++++++++++++-- tools/include/uapi/linux/bpf.h | 41 +++ tools/lib/bpf/bpf.c | 68 +++++ tools/lib/bpf/bpf.h | 5 + tools/testing/selftests/bpf/Makefile | 2 +- tools/testing/selftests/bpf/test_obj_id.c | 35 +++ tools/testing/selftests/bpf/test_progs.c | 191 +++++++++++++ 15 files changed, 798 insertions(+), 28 deletions(-) create mode 100644 tools/testing/selftests/bpf/test_obj_id.c
Signature · 1 line
2.9.3
PATCH v2 1/8 bpf: Introduce bpf_prog ID
This patch generates an unique ID for each BPF_PROG_LOAD-ed prog. It is worth to note that each BPF_PROG_LOAD-ed prog will have a different ID even they have the same bpf instructions.
The ID is generated by the existing idr_alloc_cyclic().
The ID is ranged from [1, INT_MAX). It is allocated in cyclic manner, so an ID will get reused every 2 billion BPF_PROG_LOAD.
The bpf_prog_alloc_id() is done after bpf_prog_select_runtime() because the jit process may have allocated a new prog. Hence, we need to ensure the value of pointer 'prog' will not be changed any more before storing the prog to the prog_idr.
After bpf_prog_select_runtime(), the prog is read-only. Hence, the id is stored in 'struct bpf_prog_aux'.
--- include/linux/bpf.h | 1 + kernel/bpf/syscall.c | 40 +++++++++++++++++++++++++++++++++++++++- 2 files changed, 40 insertions(+), 1 deletion(-)
include/linux/bpf.h +1 -0
@@ -171,6 +171,7 @@ struct bpf_prog_aux {atomic_t refcnt;u32 used_map_cnt;u32 max_ctx_offset; +u32 id;struct latch_tree_node ksym_tnode;struct list_head ksym_lnode;const struct bpf_verifier_ops *ops;
kernel/bpf/syscall.c +39 -1
@@ -22,8 +22,11 @@#include <linux/filter.h> #include <linux/version.h> #include <linux/kernel.h> +#include <linux/idr.h> DEFINE_PER_CPU (int, bpf_prog_active); +static DEFINE_IDR (prog_idr); +static DEFINE_SPINLOCK (prog_idr_lock);int sysctl_unprivileged_bpf_disabled__read_mostly ;
@@ -650,6 +653,34 @@ static void bpf_prog_uncharge_memlock(struct bpf_prog *prog)free_uid (user); } +static int bpf_prog_alloc_id (struct bpf_prog *prog) +{ +int id; + +spin_lock_bh (&prog_idr_lock); + id =idr_alloc_cyclic (&prog_idr, prog,1 ,INT_MAX ,GFP_ATOMIC ); +if (id >0 ) + prog->aux->id = id; +spin_unlock_bh (&prog_idr_lock); + +/* id is in [1, INT_MAX) */ +if (WARN_ON_ONCE (!id)) +return -ENOSPC ; + +return id >0 ?0 : id; +} + +static void bpf_prog_free_id (struct bpf_prog *prog) +{ +/* cBPF to eBPF migrations are currently not in the idr store. */ +if (!prog->aux->id) +return ; + +spin_lock_bh (&prog_idr_lock); +idr_remove (&prog_idr, prog->aux->id); +spin_unlock_bh (&prog_idr_lock); +} +static void __bpf_prog_put_rcu (struct rcu_head *rcu) { struct bpf_prog_aux *aux = container_of(rcu, struct bpf_prog_aux, rcu);
@@ -663,6 +694,7 @@ void bpf_prog_put(struct bpf_prog *prog) {if (atomic_dec_and_test (&prog->aux->refcnt)) {trace_bpf_prog_put_rcu (prog); +bpf_prog_free_id (prog);bpf_prog_kallsyms_del (prog);call_rcu (&prog->aux->rcu, __bpf_prog_put_rcu); }
@@ -855,15 +887,21 @@ static int bpf_prog_load(union bpf_attr *attr)if (err <0 ) goto free_used_maps; + err =bpf_prog_alloc_id (prog); +if (err) + goto free_used_maps; + err =bpf_prog_new_fd (prog);if (err <0 )/* failed to allocate fd */ - goto free_used_maps; + goto free_id;bpf_prog_kallsyms_add (prog);trace_bpf_prog_load (prog, err);return err; +free_id: +bpf_prog_free_id (prog); free_used_maps:free_used_maps (prog->aux); free_prog:
Signature · 1 line
2.9.3
PATCH v2 2/8 bpf: Introduce bpf_map ID
In reply to Martin KaFai LauThis patch generates an unique ID for each created bpf_map. The approach is similar to the earlier patch for bpf_prog ID.
It is worth to note that the bpf_map's ID and bpf_prog's ID are in two independent ID spaces and both have the same valid range:
[1, INT_MAX).
--- include/linux/bpf.h | 1 + kernel/bpf/syscall.c | 34 +++++++++++++++++++++++++++++++++- 2 files changed, 34 insertions(+), 1 deletion(-)
include/linux/bpf.h +1 -0
@@ -46,6 +46,7 @@ struct bpf_map {u32 max_entries;u32 map_flags;u32 pages; +u32 id;struct user_struct *user;const struct bpf_map_ops *ops;struct work_struct work;
kernel/bpf/syscall.c +33 -1
@@ -27,6 +27,8 @@DEFINE_PER_CPU (int, bpf_prog_active);static DEFINE_IDR (prog_idr);static DEFINE_SPINLOCK (prog_idr_lock); +static DEFINE_IDR (map_idr); +static DEFINE_SPINLOCK (map_idr_lock);int sysctl_unprivileged_bpf_disabled__read_mostly ;
@@ -117,6 +119,29 @@ static void bpf_map_uncharge_memlock(struct bpf_map *map)free_uid (user); } +static int bpf_map_alloc_id (struct bpf_map *map) +{ +int id; + +spin_lock_bh (&map_idr_lock); + id =idr_alloc_cyclic (&map_idr, map,1 ,INT_MAX ,GFP_ATOMIC ); +if (id >0 ) + map->id = id; +spin_unlock_bh (&map_idr_lock); + +if (WARN_ON_ONCE (!id)) +return -ENOSPC ; + +return id >0 ?0 : id; +} + +static void bpf_map_free_id (struct bpf_map *map) +{ +spin_lock_bh (&map_idr_lock); +idr_remove (&map_idr, map->id); +spin_unlock_bh (&map_idr_lock); +} +/* called from workqueue */ static void bpf_map_free_deferred (struct work_struct *work) {
@@ -141,6 +166,7 @@ static void bpf_map_put_uref(struct bpf_map *map)void bpf_map_put (struct bpf_map *map) {if (atomic_dec_and_test (&map->refcnt)) { +bpf_map_free_id (map);INIT_WORK (&map->work, bpf_map_free_deferred);schedule_work (&map->work); }
@@ -239,14 +265,20 @@ static int map_create(union bpf_attr *attr)if (err) goto free_map_nouncharge; + err =bpf_map_alloc_id (map); +if (err) + goto free_map; + err =bpf_map_new_fd (map);if (err <0 )/* failed to allocate fd */ - goto free_map; + goto free_id;trace_bpf_map_create (map, err);return err; +free_id: +bpf_map_free_id (map); free_map:bpf_map_uncharge_memlock (map); free_map_nouncharge:
Signature · 1 line
2.9.3
PATCH v2 3/8 bpf: Add BPF_(PROG|MAP)_GET_NEXT_ID command
In reply to Martin KaFai LauThis patch adds BPF_PROG_GET_NEXT_ID and BPF_MAP_GET_NEXT_ID to allow userspace to iterate all bpf_prog IDs and bpf_map IDs.
The API is trying to be consistent with the existing BPF_MAP_GET_NEXT_KEY.
It is currently limited to CAP_SYS_ADMIN which we can consider to lift it in followup patches.
--- include/uapi/linux/bpf.h | 7 +++++++ kernel/bpf/syscall.c | 38 ++++++++++++++++++++++++++++++++++++++ 2 files changed, 45 insertions(+)
include/uapi/linux/bpf.h +7 -0
@@ -82,6 +82,8 @@ enum bpf_cmd {BPF_PROG_ATTACH ,BPF_PROG_DETACH ,BPF_PROG_TEST_RUN , +BPF_PROG_GET_NEXT_ID , + BPF_MAP_GET_NEXT_ID, }; enum bpf_map_type {
@@ -209,6 +211,11 @@ union bpf_attr {__u32 repeat;__u32 duration; } test; + +struct {/* anonymous struct used by BPF_*_GET_NEXT_ID */ +__u32 start_id; +__u32 next_id; + }; } __attribute__((aligned(8)));/* BPF helper function descriptions:
kernel/bpf/syscall.c +38 -0
@@ -166,6 +166,7 @@ static void bpf_map_put_uref(struct bpf_map *map)void bpf_map_put (struct bpf_map *map) {if (atomic_dec_and_test (&map->refcnt)) { +/* bpf_map_free_id() must be called first */ bpf_map_free_id (map);INIT_WORK (&map->work, bpf_map_free_deferred);schedule_work (&map->work);
@@ -726,6 +727,7 @@ void bpf_prog_put(struct bpf_prog *prog) {if (atomic_dec_and_test (&prog->aux->refcnt)) {trace_bpf_prog_put_rcu (prog); +/* bpf_prog_free_id() must be called first */ bpf_prog_free_id (prog);bpf_prog_kallsyms_del (prog);call_rcu (&prog->aux->rcu, __bpf_prog_put_rcu);
@@ -1067,6 +1069,34 @@ static int bpf_prog_test_run(const union bpf_attr *attr,return ret; } +#define BPF_OBJ_GET_NEXT_ID_LAST_FIELD next_id + +static int bpf_obj_get_next_id (const union bpf_attr *attr, +union bpf_attr __user *uattr, +struct idr *idr, +spinlock_t *lock) +{ +u32 next_id = attr->start_id; +int err =0 ; + +if (CHECK_ATTR (BPF_OBJ_GET_NEXT_ID ) || next_id >=INT_MAX ) +return -EINVAL ; + +if (!capable (CAP_SYS_ADMIN )) +return -EPERM ; + + next_id++; +spin_lock_bh (lock); +if (!idr_get_next (idr, &next_id)) + err = -ENOENT ; +spin_unlock_bh (lock); + +if (!err) + err =put_user (next_id, &uattr->next_id); + +return err; +} + SYSCALL_DEFINE3(bpf, int, cmd, union bpf_attr __user *, uattr, unsigned int, size) {union bpf_attr attr = {};
@@ -1144,6 +1174,14 @@ SYSCALL_DEFINE3(bpf, int, cmd, union bpf_attr __user *, uattr, unsigned int, sizcase BPF_PROG_TEST_RUN : err =bpf_prog_test_run (&attr, uattr);break ; +case BPF_PROG_GET_NEXT_ID : + err =bpf_obj_get_next_id (&attr, uattr, + &prog_idr, &prog_idr_lock); +break ; +case BPF_MAP_GET_NEXT_ID : + err =bpf_obj_get_next_id (&attr, uattr, + &map_idr, &map_idr_lock); +break ;default : err = -EINVAL ;break ;
Signature · 1 line
2.9.3
PATCH v2 4/8 bpf: Add BPF_PROG_GET_FD_BY_ID
In reply to Martin KaFai LauAdd BPF_PROG_GET_FD_BY_ID command to allow user to get a fd from a bpf_prog's ID.
bpf_prog_inc_not_zero() is added and is called with prog_idr_lock held.
__bpf_prog_put() is also added which has the 'bool do_idr_lock' param to decide if the prog_idr_lock should be acquired when freeing the prog->id.
In the error path of bpf_prog_inc_not_zero(), it may have to call __bpf_prog_put(map, false) which does not need to take the prog_idr_lock when freeing the prog->id.
It is currently limited to CAP_SYS_ADMIN which we can consider to lift it in followup patches.
--- include/uapi/linux/bpf.h | 8 +++-- kernel/bpf/syscall.c | 91 ++++++++++++++++++++++++++++++++++++++++++------ 2 files changed, 87 insertions(+), 12 deletions(-)
include/uapi/linux/bpf.h +6 -2
@@ -84,6 +84,7 @@ enum bpf_cmd {BPF_PROG_TEST_RUN ,BPF_PROG_GET_NEXT_ID ,BPF_MAP_GET_NEXT_ID , + BPF_PROG_GET_FD_BY_ID, }; enum bpf_map_type {
@@ -212,8 +213,11 @@ union bpf_attr {__u32 duration; } test; -struct {/* anonymous struct used by BPF_*_GET_NEXT_ID */ -__u32 start_id; +struct {/* anonymous struct used by BPF_*_GET_*_ID */ +union { +__u32 start_id; +__u32 prog_id; + };__u32 next_id; }; } __attribute__((aligned(8)));
kernel/bpf/syscall.c +81 -10
146 lines not on this page · raw message
Signature · 1 line
2.9.3
PATCH v2 5/8 bpf: Add BPF_MAP_GET_FD_BY_ID
In reply to Martin KaFai LauAdd BPF_MAP_GET_FD_BY_ID command to allow user to get a fd from a bpf_map's ID.
bpf_map_inc_not_zero() is added and is called with map_idr_lock held.
__bpf_map_put() is also added which has the 'bool do_idr_lock' param to decide if the map_idr_lock should be acquired when freeing the map->id.
In the error path of bpf_map_inc_not_zero(), it may have to call __bpf_map_put(map, false) which does not need to take the map_idr_lock when freeing the map->id.
It is currently limited to CAP_SYS_ADMIN which we can consider to lift it in followup patches.
--- include/uapi/linux/bpf.h | 2 + kernel/bpf/syscall.c | 95 +++++++++++++++++++++++++++++++++++++++++++----- 2 files changed, 87 insertions(+), 10 deletions(-)
include/uapi/linux/bpf.h +2 -0
@@ -85,6 +85,7 @@ enum bpf_cmd {BPF_PROG_GET_NEXT_ID ,BPF_MAP_GET_NEXT_ID ,BPF_PROG_GET_FD_BY_ID , + BPF_MAP_GET_FD_BY_ID, }; enum bpf_map_type {
@@ -217,6 +218,7 @@ union bpf_attr {union {__u32 start_id;__u32 prog_id; +__u32 map_id; };__u32 next_id; };
kernel/bpf/syscall.c +85 -10
145 lines not on this page · raw message
Signature · 1 line
2.9.3
PATCH v2 6/8 bpf: Add jited_len to struct bpf_prog
In reply to Martin KaFai LauAdd jited_len to struct bpf_prog. It will be useful for the struct bpf_prog_info which will be added in the later patch.
--- arch/arm64/net/bpf_jit_comp.c | 1 + arch/powerpc/net/bpf_jit_comp64.c | 1 + arch/s390/net/bpf_jit_comp.c | 1 + arch/sparc/net/bpf_jit_comp_64.c | 1 + arch/x86/net/bpf_jit_comp.c | 1 + include/linux/filter.h | 1 + 6 files changed, 6 insertions(+)
arch/arm64/net/bpf_jit_comp.c +1 -0
@@ -900,6 +900,7 @@ struct bpf_prog *bpf_int_jit_compile(struct bpf_prog *prog)bpf_jit_binary_lock_ro (header); prog->bpf_func = (void *)ctx.image; prog->jited =1 ; + prog->jited_len = image_size; out_off:kfree (ctx.offset);
arch/powerpc/net/bpf_jit_comp64.c +1 -0
@@ -1052,6 +1052,7 @@ struct bpf_prog *bpf_int_jit_compile(struct bpf_prog *fp) fp->bpf_func = (void *)image; fp->jited =1 ; + fp->jited_len = alloclen;bpf_flush_icache (bpf_hdr, (u8 *)bpf_hdr + (bpf_hdr->pages *PAGE_SIZE ));
arch/s390/net/bpf_jit_comp.c +1 -0
@@ -1329,6 +1329,7 @@ struct bpf_prog *bpf_int_jit_compile(struct bpf_prog *fp)bpf_jit_binary_lock_ro (header); fp->bpf_func = (void *) jit.prg_buf; fp->jited =1 ; + fp->jited_len = jit.size; free_addrs:kfree (jit.addrs); out:
arch/sparc/net/bpf_jit_comp_64.c +1 -0
@@ -1555,6 +1555,7 @@ struct bpf_prog *bpf_int_jit_compile(struct bpf_prog *prog) prog->bpf_func = (void *)ctx.image; prog->jited =1 ; + prog->jited_len = image_size; out_off:kfree (ctx.offset);
arch/x86/net/bpf_jit_comp.c +1 -0
@@ -1162,6 +1162,7 @@ struct bpf_prog *bpf_int_jit_compile(struct bpf_prog *prog)bpf_jit_binary_lock_ro (header); prog->bpf_func = (void *)image; prog->jited =1 ; + prog->jited_len = proglen; }else { prog = orig_prog; }
include/linux/filter.h +1 -0
@@ -429,6 +429,7 @@ struct bpf_prog {kmemcheck_bitfield_end (meta);enum bpf_prog_type type;/* Type of BPF program */ u32 len;/* Number of filter blocks */ +u32 jited_len;/* Size of jited insns in bytes */ u8 tag[BPF_TAG_SIZE ];struct bpf_prog_aux *aux;/* Auxiliary fields */ struct sock_fprog_kern *orig_prog;/* Original BPF program */
Signature · 1 line
2.9.3
PATCH v2 7/8 bpf: Add BPF_OBJ_GET_INFO_BY_FD
In reply to Martin KaFai LauA single BPF_OBJ_GET_INFO_BY_FD cmd is used to obtain the info for both bpf_prog and bpf_map. The kernel can figure out the fd is associated with a bpf_prog or bpf_map.
The suggested struct bpf_prog_info and struct bpf_map_info are not meant to be a complete list and it is not the goal of this patch. New fields can be added in the future patch.
The focus of this patch is to create the interface, BPF_OBJ_GET_INFO_BY_FD cmd for exposing the bpf_prog's and bpf_map's info.
The obj's info, which will be extended (and get bigger) over time, is separated from the bpf_attr to avoid bloating the bpf_attr.
--- include/linux/filter.h | 2 - include/uapi/linux/bpf.h | 28 ++++++++ kernel/bpf/syscall.c | 163 ++++++++++++++++++++++++++++++++++++++++++----- 3 files changed, 174 insertions(+), 19 deletions(-)
include/linux/filter.h +0 -2
@@ -66,8 +66,6 @@ struct bpf_prog_aux;/* BPF program can access up to 512 bytes of stack space. */ #define MAX_BPF_STACK 512 -#define BPF_TAG_SIZE 8 -/* Helper macros for filter block array initializers. */ /* ALU ops on registers, bpf_add|sub|...: dst_reg += src_reg */
include/uapi/linux/bpf.h +28 -0
@@ -86,6 +86,7 @@ enum bpf_cmd {BPF_MAP_GET_NEXT_ID ,BPF_PROG_GET_FD_BY_ID ,BPF_MAP_GET_FD_BY_ID , + BPF_OBJ_GET_INFO_BY_FD, }; enum bpf_map_type {
@@ -222,6 +223,12 @@ union bpf_attr { };__u32 next_id; }; + +struct {/* anonymous struct used by BPF_OBJ_GET_INFO_BY_FD */ +__u32 bpf_fd; +__u32 info_len; +__aligned_u64 info; + } info; } __attribute__((aligned(8)));/* BPF helper function descriptions:
@@ -683,4 +690,25 @@ struct xdp_md { __u32 data_end; }; +#define BPF_TAG_SIZE 8 + +struct bpf_prog_info { +__u32 type; +__u32 id; +__u8 tag[BPF_TAG_SIZE ]; +__u32 jited_prog_len; +__u32 xlated_prog_len; +__aligned_u64 jited_prog_insns; +__aligned_u64 xlated_prog_insns; +} __attribute__((aligned (8 ))); + +struct bpf_map_info { +__u32 type; +__u32 id; +__u32 key_size; +__u32 value_size; +__u32 max_entries; +__u32 map_flags; +} __attribute__((aligned (8 ))); +#endif /* _UAPI__LINUX_BPF_H__ */
kernel/bpf/syscall.c +146 -17
181 lines not on this page · raw message
Signature · 1 line
2.9.3
PATCH v2 8/8 bpf: Test for bpf ID
In reply to Martin KaFai LauAdd test to exercise the bpf_prog/map id generation, bpf_(prog|map)_get_next_id(), bpf_(prog|map)_get_fd_by_id() and bpf_get_obj_info_by_fd().
--- tools/include/uapi/linux/bpf.h | 41 +++++++ tools/lib/bpf/bpf.c | 68 +++++++++++ tools/lib/bpf/bpf.h | 5 + tools/testing/selftests/bpf/Makefile | 2 +- tools/testing/selftests/bpf/test_obj_id.c | 35 ++++++ tools/testing/selftests/bpf/test_progs.c | 191 ++++++++++++++++++++++++++++++ 6 files changed, 341 insertions(+), 1 deletion(-) create mode 100644 tools/testing/selftests/bpf/test_obj_id.c
tools/include/uapi/linux/bpf.h +41 -0
@@ -82,6 +82,11 @@ enum bpf_cmd {BPF_PROG_ATTACH ,BPF_PROG_DETACH ,BPF_PROG_TEST_RUN , +BPF_PROG_GET_NEXT_ID , +BPF_MAP_GET_NEXT_ID , +BPF_PROG_GET_FD_BY_ID , +BPF_MAP_GET_FD_BY_ID , + BPF_OBJ_GET_INFO_BY_FD, }; enum bpf_map_type {
@@ -209,6 +214,21 @@ union bpf_attr {__u32 repeat;__u32 duration; } test; + +struct {/* anonymous struct used by BPF_*_GET_*_ID */ +union { +__u32 start_id; +__u32 prog_id; +__u32 map_id; + }; +__u32 next_id; + }; + +struct {/* anonymous struct used by BPF_OBJ_GET_INFO_BY_FD */ +__u32 bpf_fd; +__u32 info_len; +__aligned_u64 info; + } info; } __attribute__((aligned(8)));/* BPF helper function descriptions:
@@ -670,4 +690,25 @@ struct xdp_md { __u32 data_end; }; +#define BPF_TAG_SIZE 8 + +struct bpf_prog_info { +__u32 type; +__u32 id; +__u8 tag[BPF_TAG_SIZE ]; +__u32 jited_prog_len; +__u32 xlated_prog_len; +__aligned_u64 jited_prog_insns; +__aligned_u64 xlated_prog_insns; +} __attribute__((aligned (8 ))); + +struct bpf_map_info { +__u32 type; +__u32 id; +__u32 key_size; +__u32 value_size; +__u32 max_entries; +__u32 map_flags; +} __attribute__((aligned (8 ))); +#endif /* _UAPI__LINUX_BPF_H__ */
tools/lib/bpf/bpf.c +68 -0
71 lines not on this page · raw message
tools/lib/bpf/bpf.h +5 -0
@@ -54,5 +54,10 @@ int bpf_prog_detach(int attachable_fd, enum bpf_attach_type type);int bpf_prog_test_run (int prog_fd,int repeat,void *data,__u32 size,void *data_out,__u32 *size_out,__u32 *retval,__u32 *duration); +int bpf_prog_get_next_id (__u32 start_id,__u32 *next_id); +int bpf_map_get_next_id (__u32 start_id,__u32 *next_id); +int bpf_prog_get_fd_by_id (__u32 id); +int bpf_map_get_fd_by_id (__u32 id); +int bpf_obj_get_info_by_fd (int prog_fd,void *info,__u32 *info_len);#endif
tools/testing/selftests/bpf/Makefile +1 -1
@@ -14,7 +14,7 @@ LDLIBS += -lcap -lelf TEST_GEN_PROGS = test_verifier test_tag test_maps test_lru_map test_lpm_map test_progs \ test_align -TEST_GEN_FILES = test_pkt_access.o test_xdp.o test_l4lb.o test_tcp_estats.o +TEST_GEN_FILES = test_pkt_access.o test_xdp.o test_l4lb.o test_tcp_estats.o test_obj_id.o TEST_PROGS := test_kmod.sh
tools/testing/selftests/bpf/test_obj_id.c new file +35 -0
@@ -0,0 +1,35 @@ +/* Copyright (c) 2017 Facebook +* +* This program is free software; you can redistribute it and/or +* modify it under the terms of version 2 of the GNU General Public +* License as published by the Free Software Foundation. +*/ +#include <stddef.h> +#include <linux/bpf.h> +#include <linux/pkt_cls.h> +#include "bpf_helpers.h" + +/* It is a dumb bpf program such that it must have no +* issue to be loaded since testing the verifier is +* not the focus here. +*/ + +int _version SEC("version") = 1; + +struct bpf_map_def SEC("maps") test_map_id = { + .type = BPF_MAP_TYPE_ARRAY, + .key_size = sizeof(__u32), + .value_size = sizeof(__u64), + .max_entries = 1, +}; + +SEC("test_prog_id") +int test_prog_id (struct __sk_buff *skb) +{ +__u32 key =0 ; +__u64 *value; + + value =bpf_map_lookup_elem (&test_map_id, &key); + +return TC_ACT_OK ; +}
tools/testing/selftests/bpf/test_progs.c +191 -0
215 lines not on this page · raw message
Signature · 1 line
2.9.3
David Miller
maintainerFrom: Martin KaFai Lau <[email protected]>
Date: Wed, 31 May 2017 11:58:54 -0700
Quoted 10 lines
This patch series:
1) Introduce ID for bothbpf_progandbpf_map.
2) Add bpf commands to iterate the prog IDs and map IDs of the system.
3) Add bpf commands to get a prog/map fd from an ID
4) Add bpf command to get prog/map info from a fd. The prog/map info is a jump start in this patchset and it is not meant to be a complete list. They can be extended in the future patches.
Quoted 7 lines
v2:
Compiler warning fixes:
- Removelockdep_is_held()usage. Add comment
to explain the lock situation instead.
- Add static for idr related variables
- Add__userto the uattr param inbpf_prog_get_info_by_fd()andbpf_map_get_info_by_fd().
Series applied, thanks Martin.
Quoted 21 lines · David Miller
From: Martin KaFai Lau <[email protected]>
Date: Wed, 31 May 2017 11:58:54 -0700Quoted 10 lines
This patch series:
1) Introduce ID for bothbpf_progandbpf_map.
2) Add bpf commands to iterate the prog IDs and map IDs of the system.
3) Add bpf commands to get a prog/map fd from an ID
4) Add bpf command to get prog/map info from a fd. The prog/map info is a jump start in this patchset and it is not meant to be a complete list. They can be extended in the future patches.Quoted 7 lines
v2:
Compiler warning fixes:
- Removelockdep_is_held()usage. Add comment
to explain the lock situation instead.
- Add static for idr related variables
- Add__userto the uattr param inbpf_prog_get_info_by_fd()andbpf_map_get_info_by_fd().
Quoted 1 line
Series applied, thanks Martin.
Patch 1 may not apply cleanly due to another newly added field in 'struct bpf_prog_aux' on May 31.
Should I respin?
Quoted 9 lines · Martin KaFai Lau
This patch series:
1) Introduce ID for bothbpf_progandbpf_map.
2) Add bpf commands to iterate the prog IDs and map IDs of the system.
3) Add bpf commands to get a prog/map fd from an ID
4) Add bpf command to get prog/map info from a fd. The prog/map info is a jump start in this patchset and it is not meant to be a complete list. They can be extended in the future patches.
Hi! IIUC there were plans at some point to store the BPF byte code in the kernel, the way it was loaded from the user space and before it went through the verifier. Are you still planning on implementing that? It would be handy for offloads to have the original byte code, things like call inlining make translations of maps calls a bit challenging, since we try to run through the verifier again..
Quoted 11 lines · Jakub Kicinski
Quoted 9 lines · Martin KaFai Lau
This patch series:
1) Introduce ID for bothbpf_progandbpf_map.
2) Add bpf commands to iterate the prog IDs and map IDs of the system.
3) Add bpf commands to get a prog/map fd from an ID
4) Add bpf command to get prog/map info from a fd. The prog/map info is a jump start in this patchset and it is not meant to be a complete list. They can be extended in the future patches.
Quoted 7 lines
Hi! IIUC there were plans at some point to store the BPF byte code in the kernel, the way it was loaded from the user space and before it went through the verifier. Are you still planning on implementing that? It would be handy for offloads to have the original byte code, things like call inlining make translations of maps calls a bit challenging, since we try to run through the verifier again..
Save the instructions:
https://github.com/dsahern/linux/commit/5315578db7b0886a3e8e3bef6a56e828ae2bd2c4
Let userspace read it back:
https://github.com/dsahern/linux/commit/619982064b9b582fc5d4a504feffca1730610c4e
One more in between in the branch:
https://github.com/dsahern/linux/tree/bpf/retrieve-bpf-wip
Now that the id code is in, it needs to be returned on link dumps, route dumps, etc and accessible via fdinfo. The id can be turned into an fd and the fd read using the above patches.
Quoted 26 lines · David Ahern
Quoted 11 lines · Jakub Kicinski
Quoted 9 lines · Martin KaFai Lau
This patch series:
1) Introduce ID for bothbpf_progandbpf_map.
2) Add bpf commands to iterate the prog IDs and map IDs of the system.
3) Add bpf commands to get a prog/map fd from an ID
4) Add bpf command to get prog/map info from a fd. The prog/map info is a jump start in this patchset and it is not meant to be a complete list. They can be extended in the future patches.Quoted 7 lines
Hi! IIUC there were plans at some point to store the BPF byte code in the kernel, the way it was loaded from the user space and before it went through the verifier. Are you still planning on implementing that? It would be handy for offloads to have the original byte code, things like call inlining make translations of maps calls a bit challenging, since we try to run through the verifier again..
Save the instructions:
https://github.com/dsahern/linux/commit/5315578db7b0886a3e8e3bef6a56e828ae2bd2c4Let userspace read it back:
https://github.com/dsahern/linux/commit/619982064b9b582fc5d4a504feffca1730610c4e
Quoted 6 lines
One more in between in the branch:
https://github.com/dsahern/linux/tree/bpf/retrieve-bpf-wipNow that the id code is in, it needs to be returned on link dumps, route dumps, etc and accessible via fdinfo. The id can be turned into an fd and the fd read using the above patches.
what problem are we trying to solve?
If we don't agree on the problem, we won't be able to agree on the solution.
Sounds to me that Jakub wants to translate lookup/update helper calls for JITing and it's difficult due to inlining optimization. In such case isn't the easiest solution to disable inlining when JIT to NFP is on?
Dave's case is to be able to retrieve a cgroup_sock program used for vrf. Such prog doesn't have any maps and I don't see why returning real insns is not enough.
As Martin said there is work in progress patches that return IDs for programs attached to everything: cgroup_sock hook, xdp, etc. The user can get prog ID, convert to FD and dump all insns. Why this is not enough for VRF introspection?
Quoted 4 lines · Alexei Starovoitov
what problem are we trying to solve?
If we don't agree on the problem, we won't be able to agree on the solution.
I want the ability to retrieve the BPF instructions pushed to the kernel. Not just for cgroups and VRF, but everywhere - cgroups, sockets, xdp, filters, etc. I have this stated many times, including to you at netconf in April. From that discussion and the discussion on the RFC patch I sent in February, I thought we had an agreement that saving the instructions was the first step.
Quentin at 6wind has expressed a similar interest for cls_bpf and act_bpf code.
I read Jakub's email as wanting the same but for XDP.
The patches I referenced earlier save the original instructions and enable them to be read by userspace from an fd return by the bpf syscall. Combine that with the ID and we have a solution.
Quoted 13 lines · David Ahern
Quoted 4 lines · Alexei Starovoitov
what problem are we trying to solve?
If we don't agree on the problem, we won't be able to agree on the solution.I want the ability to retrieve the BPF instructions pushed to the kernel. Not just for cgroups and VRF, but everywhere - cgroups, sockets, xdp, filters, etc. I have this stated many times, including to you at netconf in April. From that discussion and the discussion on the RFC patch I sent in February, I thought we had an agreement that saving the instructions was the first step.
Quoted 8 lines
Quentin at 6wind has expressed a similar interest for
cls_bpfandact_bpfcode.I read Jakub's email as wanting the same but for XDP.
The patches I referenced earlier save the original instructions and enable them to be read by userspace from an fd return by the bpf syscall. Combine that with the ID and we have a solution.
Please explain the problem instead of pushing for 'solution'. In this case I do not see a problem that saving original instructions will solve.
'I want to retrieve original instructions' is not a problem. It's a push for 'solution'. Explaining 'why' you want to see original instructions would describe the actual problem.
If you're trying to debug something you're interested in original source code and in the instructions that kernel is running. To correlate to source code we have prog_tag (that was computed over original insns).
To see kernel instructions in the interpreter and JITed assembler we have this set of patches.
Original instructions are not useful for debugging, since they have map_fds which can be long gone when program is running, therefore to solve introspection problem we need to look into real kernel instructions.
My understanding that 6wind wants to see original instructions to accelerate them somehow using out of tree technology. I'm not interested to help that cause. I also suspect that retrieving kernel instructions will not be much different from that point of view, but at least returning kernel insns is solving introspection problem for everyone.
Returning kernel insns also doesn't burn unnecessary memory, whereas original insns will be there as dead weight. Hence before we add them we need to be absolutely clear that there is no cheaper alternative possible.
David Miller
maintainerFrom: Alexei Starovoitov <[email protected]>
Date: Thu, 1 Jun 2017 11:27:56 -0700
Quoted 4 lines
Original instructions are not useful for debugging, since they have
map_fdswhich can be long gone when program is running, therefore to solve introspection problem we need to look into real kernel instructions.
The only possible legitimate use I see for the original instructions is checkpoint/restart.
If 6wind wants this for "external acceleration" or whatever, like Alexei I am not interested in facilitating that at all.
Quoted 8 lines · David Miller
From: Alexei Starovoitov <[email protected]>
Date: Thu, 1 Jun 2017 11:27:56 -0700Quoted 4 lines
Original instructions are not useful for debugging, since they have
map_fdswhich can be long gone when program is running, therefore to solve introspection problem we need to look into real kernel instructions.
Quoted 5 lines
The only possible legitimate use I see for the original instructions is checkpoint/restart.
If 6wind wants this for "external acceleration" or whatever, like Alexei I am not interested in facilitating that at all.
+1
I will try disabling the inlining then.
Quoted 3 lines · Alexei Starovoitov
'I want to retrieve original instructions' is not a problem. It's a push for 'solution'. Explaining 'why' you want to see original instructions would describe the actual problem.
I have explained this.
You are creating this hyper-complex almost completely invisible infrastructure. You are enabling binary blobs that can bypass the network stack and modify packets with almost no introspection on what is happening. BPF code can from a variety of sources -- OS vendors, upstream repos, 3rd party vendors (eg., H/W vendors), and "in-house" development. Each will swear to the end that any observed problem is not with their code. In my experience, it falls on to the OS and kernel experts to figure out why Linux is breaking something. To do that we need tools to look at what code is running where and something that can be used in production environments not requiring a disruption to the service that the box is providing.
David Miller
maintainerFrom: David Ahern <[email protected]>
Date: Thu, 1 Jun 2017 12:52:28 -0600
Quoted 7 lines · Alexei Starovoitov
Quoted 3 lines
'I want to retrieve original instructions' is not a problem. It's a push for 'solution'. Explaining 'why' you want to see original instructions would describe the actual problem.
I have explained this.
Quoted 11 lines
You are creating this hyper-complex almost completely invisible infrastructure. You are enabling binary blobs that can bypass the network stack and modify packets with almost no introspection on what is happening. BPF code can from a variety of sources -- OS vendors, upstream repos, 3rd party vendors (eg., H/W vendors), and "in-house" development. Each will swear to the end that any observed problem is not with their code. In my experience, it falls on to the OS and kernel experts to figure out why Linux is breaking something. To do that we need tools to look at what code is running where and something that can be used in production environments not requiring a disruption to the service that the box is providing.
I'm not convinced that the verifier processed instruction stream cannot provide that facility properly.
In fact, because of how the maps and tail calls work, you can only figure out what is really executing by looking at the final processed instruction stream.
Quoted 7 lines · David Ahern
Quoted 3 lines · Alexei Starovoitov
'I want to retrieve original instructions' is not a problem. It's a push for 'solution'. Explaining 'why' you want to see original instructions would describe the actual problem.
I have explained this.
Quoted 11 lines
You are creating this hyper-complex almost completely invisible infrastructure. You are enabling binary blobs that can bypass the network stack and modify packets with almost no introspection on what is happening. BPF code can from a variety of sources -- OS vendors, upstream repos, 3rd party vendors (eg., H/W vendors), and "in-house" development. Each will swear to the end that any observed problem is not with their code. In my experience, it falls on to the OS and kernel experts to figure out why Linux is breaking something. To do that we need tools to look at what code is running where and something that can be used in production environments not requiring a disruption to the service that the box is providing.
Forgive my ignorance, but is it possible to dump code of a loaded module out of the kernel?
Quoted 7 lines · David Ahern
Quoted 3 lines · Alexei Starovoitov
'I want to retrieve original instructions' is not a problem. It's a push for 'solution'. Explaining 'why' you want to see original instructions would describe the actual problem.
I have explained this.
Quoted 11 lines
You are creating this hyper-complex almost completely invisible infrastructure. You are enabling binary blobs that can bypass the network stack and modify packets with almost no introspection on what is happening. BPF code can from a variety of sources -- OS vendors, upstream repos, 3rd party vendors (eg., H/W vendors), and "in-house" development. Each will swear to the end that any observed problem is not with their code. In my experience, it falls on to the OS and kernel experts to figure out why Linux is breaking something. To do that we need tools to look at what code is running where and something that can be used in production environments not requiring a disruption to the service that the box is providing.
You saw patch 7/8, right?
since I'm not following what exactly you're concerned about.
This patch set provided a way to retrieve post-verifier, post-blinding
instruction stream that gives users a way to know exactly what is running. Original instruction stream is not the one that is executed. It's merely an interface between kernel and user space.
Before that stage the clang/llvm did many code transformations and
optimizations on original source code and after that verifier,
context rewriter, inliner, constant blinding did transformations on
these insns as well.
If there is a bug somewhere in all these transformations it can be anywhere in clang, llvm optimizer, llvm codegen, elf or bcc loader and in kernel side transformations. Yes. There can be bugs, but we cannot keep all these stages in the kernel. I don't mind dumping insn stream for debugging while doing these stages (just like llvm has -print-before-all flag), but keeping all the intermediate stages don't make sense to me. In that sense 'original instruction stream' to me is one of the intermediate stages where source code in C crossed user->kernel boundary.
I'd rather store more information about original C code than this user->kernel instruction stream. That's where CTF is heading. To provide info about types, names, etc. For both progs and maps.
I don't mind storing even that 'original instruction stream' _if_ there is a solid reason. I just didn't hear one so far.
I can imagine somebody saying that there is a bug in context rewriter and xlated_prog_insns are accessing wrong field. That's bad, but how keeping original_prog_insns will help such case?
And how such bug is different from llvm generating wrong code ? If there is a bug anywhere in that transformation pipeline I'd want to give original source code and final outcome to support people. In practice everything is more complex, since maps are dynamic, tail_calls are dynamic, the code flow changes. Debugging is not easy and this patch set is the first step toward better debuggability. I'm all for it, but statements like "without original insns it's not debuggable" are concerning, since we either don't explain the APIs well enough or understanding of the use case is missing on our side.
Quoted 1 line · Alexei Starovoitov
You saw patch 7/8, right?
Apparently, not close enough. Nothing in the commit message mentioned returning instructions. I skimmed the patch and filled in that GET_INFO was returning just the meta-data.