| Message ID | 153902585547.8888.12194884958727189508.stgit@kernel |
|---|---|
| State | Changes Requested, archived |
| Delegated to: | BPF Maintainers |
| Headers | show |
| Series | Implement queue/stack maps | expand |
Actually, does it make sense to implement a list_map that supports both pop_head() and pop_tail()? Maybe gate one of the pop operations with options? I am asking because mixing stack with stack trace is still confusing after this patch. Thanks, Song On Mon, Oct 8, 2018 at 12:11 PM Mauricio Vasquez B <mauricio.vasquez@polito.it> wrote: > > In the following patches queue and stack maps (FIFO and LIFO > datastructures) will be implemented. In order to avoid confusion and > a possible name clash rename stack_map_ops to stack_trace_map_ops > > Signed-off-by: Mauricio Vasquez B <mauricio.vasquez@polito.it> > --- > include/linux/bpf_types.h | 2 +- > kernel/bpf/stackmap.c | 2 +- > 2 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/include/linux/bpf_types.h b/include/linux/bpf_types.h > index 5432f4c9f50e..658509daacd4 100644 > --- a/include/linux/bpf_types.h > +++ b/include/linux/bpf_types.h > @@ -51,7 +51,7 @@ BPF_MAP_TYPE(BPF_MAP_TYPE_LRU_HASH, htab_lru_map_ops) > BPF_MAP_TYPE(BPF_MAP_TYPE_LRU_PERCPU_HASH, htab_lru_percpu_map_ops) > BPF_MAP_TYPE(BPF_MAP_TYPE_LPM_TRIE, trie_map_ops) > #ifdef CONFIG_PERF_EVENTS > -BPF_MAP_TYPE(BPF_MAP_TYPE_STACK_TRACE, stack_map_ops) > +BPF_MAP_TYPE(BPF_MAP_TYPE_STACK_TRACE, stack_trace_map_ops) > #endif > BPF_MAP_TYPE(BPF_MAP_TYPE_ARRAY_OF_MAPS, array_of_maps_map_ops) > BPF_MAP_TYPE(BPF_MAP_TYPE_HASH_OF_MAPS, htab_of_maps_map_ops) > diff --git a/kernel/bpf/stackmap.c b/kernel/bpf/stackmap.c > index 8061a439ef18..bb41e293418d 100644 > --- a/kernel/bpf/stackmap.c > +++ b/kernel/bpf/stackmap.c > @@ -600,7 +600,7 @@ static void stack_map_free(struct bpf_map *map) > put_callchain_buffers(); > } > > -const struct bpf_map_ops stack_map_ops = { > +const struct bpf_map_ops stack_trace_map_ops = { > .map_alloc = stack_map_alloc, > .map_free = stack_map_free, > .map_get_next_key = stack_map_get_next_key, >
On 10/08/2018 08:40 PM, Song Liu wrote: > Actually, does it make sense to implement a list_map that supports > both pop_head() > and pop_tail()? Maybe gate one of the pop operations with options? The main issue with this approach is the mapping to the system calls. Adding a flag would complicate things a bit because lookup nor lookup_and_delete have a flag argument. > I am asking because mixing stack with stack trace is still confusing > after this patch. > > Thanks, > Song > > On Mon, Oct 8, 2018 at 12:11 PM Mauricio Vasquez B > <mauricio.vasquez@polito.it> wrote: >> In the following patches queue and stack maps (FIFO and LIFO >> datastructures) will be implemented. In order to avoid confusion and >> a possible name clash rename stack_map_ops to stack_trace_map_ops >> >> Signed-off-by: Mauricio Vasquez B <mauricio.vasquez@polito.it> >> --- >> include/linux/bpf_types.h | 2 +- >> kernel/bpf/stackmap.c | 2 +- >> 2 files changed, 2 insertions(+), 2 deletions(-) >> >> diff --git a/include/linux/bpf_types.h b/include/linux/bpf_types.h >> index 5432f4c9f50e..658509daacd4 100644 >> --- a/include/linux/bpf_types.h >> +++ b/include/linux/bpf_types.h >> @@ -51,7 +51,7 @@ BPF_MAP_TYPE(BPF_MAP_TYPE_LRU_HASH, htab_lru_map_ops) >> BPF_MAP_TYPE(BPF_MAP_TYPE_LRU_PERCPU_HASH, htab_lru_percpu_map_ops) >> BPF_MAP_TYPE(BPF_MAP_TYPE_LPM_TRIE, trie_map_ops) >> #ifdef CONFIG_PERF_EVENTS >> -BPF_MAP_TYPE(BPF_MAP_TYPE_STACK_TRACE, stack_map_ops) >> +BPF_MAP_TYPE(BPF_MAP_TYPE_STACK_TRACE, stack_trace_map_ops) >> #endif >> BPF_MAP_TYPE(BPF_MAP_TYPE_ARRAY_OF_MAPS, array_of_maps_map_ops) >> BPF_MAP_TYPE(BPF_MAP_TYPE_HASH_OF_MAPS, htab_of_maps_map_ops) >> diff --git a/kernel/bpf/stackmap.c b/kernel/bpf/stackmap.c >> index 8061a439ef18..bb41e293418d 100644 >> --- a/kernel/bpf/stackmap.c >> +++ b/kernel/bpf/stackmap.c >> @@ -600,7 +600,7 @@ static void stack_map_free(struct bpf_map *map) >> put_callchain_buffers(); >> } >> >> -const struct bpf_map_ops stack_map_ops = { >> +const struct bpf_map_ops stack_trace_map_ops = { >> .map_alloc = stack_map_alloc, >> .map_free = stack_map_free, >> .map_get_next_key = stack_map_get_next_key, >>
diff --git a/include/linux/bpf_types.h b/include/linux/bpf_types.h index 5432f4c9f50e..658509daacd4 100644 --- a/include/linux/bpf_types.h +++ b/include/linux/bpf_types.h @@ -51,7 +51,7 @@ BPF_MAP_TYPE(BPF_MAP_TYPE_LRU_HASH, htab_lru_map_ops) BPF_MAP_TYPE(BPF_MAP_TYPE_LRU_PERCPU_HASH, htab_lru_percpu_map_ops) BPF_MAP_TYPE(BPF_MAP_TYPE_LPM_TRIE, trie_map_ops) #ifdef CONFIG_PERF_EVENTS -BPF_MAP_TYPE(BPF_MAP_TYPE_STACK_TRACE, stack_map_ops) +BPF_MAP_TYPE(BPF_MAP_TYPE_STACK_TRACE, stack_trace_map_ops) #endif BPF_MAP_TYPE(BPF_MAP_TYPE_ARRAY_OF_MAPS, array_of_maps_map_ops) BPF_MAP_TYPE(BPF_MAP_TYPE_HASH_OF_MAPS, htab_of_maps_map_ops) diff --git a/kernel/bpf/stackmap.c b/kernel/bpf/stackmap.c index 8061a439ef18..bb41e293418d 100644 --- a/kernel/bpf/stackmap.c +++ b/kernel/bpf/stackmap.c @@ -600,7 +600,7 @@ static void stack_map_free(struct bpf_map *map) put_callchain_buffers(); } -const struct bpf_map_ops stack_map_ops = { +const struct bpf_map_ops stack_trace_map_ops = { .map_alloc = stack_map_alloc, .map_free = stack_map_free, .map_get_next_key = stack_map_get_next_key,
In the following patches queue and stack maps (FIFO and LIFO datastructures) will be implemented. In order to avoid confusion and a possible name clash rename stack_map_ops to stack_trace_map_ops Signed-off-by: Mauricio Vasquez B <mauricio.vasquez@polito.it> --- include/linux/bpf_types.h | 2 +- kernel/bpf/stackmap.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-)