2019-05-29 22:18:09 +08:00
|
|
|
// SPDX-License-Identifier: GPL-2.0-only
|
2014-11-14 09:36:45 +08:00
|
|
|
/* Copyright (c) 2011-2014 PLUMgrid, http://plumgrid.com
|
bpf: pre-allocate hash map elements
If kprobe is placed on spin_unlock then calling kmalloc/kfree from
bpf programs is not safe, since the following dead lock is possible:
kfree->spin_lock(kmem_cache_node->lock)...spin_unlock->kprobe->
bpf_prog->map_update->kmalloc->spin_lock(of the same kmem_cache_node->lock)
and deadlocks.
The following solutions were considered and some implemented, but
eventually discarded
- kmem_cache_create for every map
- add recursion check to slow-path of slub
- use reserved memory in bpf_map_update for in_irq or in preempt_disabled
- kmalloc via irq_work
At the end pre-allocation of all map elements turned out to be the simplest
solution and since the user is charged upfront for all the memory, such
pre-allocation doesn't affect the user space visible behavior.
Since it's impossible to tell whether kprobe is triggered in a safe
location from kmalloc point of view, use pre-allocation by default
and introduce new BPF_F_NO_PREALLOC flag.
While testing of per-cpu hash maps it was discovered
that alloc_percpu(GFP_ATOMIC) has odd corner cases and often
fails to allocate memory even when 90% of it is free.
The pre-allocation of per-cpu hash elements solves this problem as well.
Turned out that bpf_map_update() quickly followed by
bpf_map_lookup()+bpf_map_delete() is very common pattern used
in many of iovisor/bcc/tools, so there is additional benefit of
pre-allocation, since such use cases are must faster.
Since all hash map elements are now pre-allocated we can remove
atomic increment of htab->count and save few more cycles.
Also add bpf_map_precharge_memlock() to check rlimit_memlock early to avoid
large malloc/free done by users who don't have sufficient limits.
Pre-allocation is done with vmalloc and alloc/free is done
via percpu_freelist. Here are performance numbers for different
pre-allocation algorithms that were implemented, but discarded
in favor of percpu_freelist:
1 cpu:
pcpu_ida 2.1M
pcpu_ida nolock 2.3M
bt 2.4M
kmalloc 1.8M
hlist+spinlock 2.3M
pcpu_freelist 2.6M
4 cpu:
pcpu_ida 1.5M
pcpu_ida nolock 1.8M
bt w/smp_align 1.7M
bt no/smp_align 1.1M
kmalloc 0.7M
hlist+spinlock 0.2M
pcpu_freelist 2.0M
8 cpu:
pcpu_ida 0.7M
bt w/smp_align 0.8M
kmalloc 0.4M
pcpu_freelist 1.5M
32 cpu:
kmalloc 0.13M
pcpu_freelist 0.49M
pcpu_ida nolock is a modified percpu_ida algorithm without
percpu_ida_cpu locks and without cross-cpu tag stealing.
It's faster than existing percpu_ida, but not as fast as pcpu_freelist.
bt is a variant of block/blk-mq-tag.c simlified and customized
for bpf use case. bt w/smp_align is using cache line for every 'long'
(similar to blk-mq-tag). bt no/smp_align allocates 'long'
bitmasks continuously to save memory. It's comparable to percpu_ida
and in some cases faster, but slower than percpu_freelist
hlist+spinlock is the simplest free list with single spinlock.
As expeceted it has very bad scaling in SMP.
kmalloc is existing implementation which is still available via
BPF_F_NO_PREALLOC flag. It's significantly slower in single cpu and
in 8 cpu setup it's 3 times slower than pre-allocation with pcpu_freelist,
but saves memory, so in cases where map->max_entries can be large
and number of map update/delete per second is low, it may make
sense to use it.
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2016-03-08 13:57:15 +08:00
|
|
|
* Copyright (c) 2016 Facebook
|
2014-11-14 09:36:45 +08:00
|
|
|
*/
|
|
|
|
#include <linux/bpf.h>
|
2018-08-09 23:55:20 +08:00
|
|
|
#include <linux/btf.h>
|
2014-11-14 09:36:45 +08:00
|
|
|
#include <linux/jhash.h>
|
|
|
|
#include <linux/filter.h>
|
2017-03-08 12:00:13 +08:00
|
|
|
#include <linux/rculist_nulls.h>
|
2018-08-23 05:49:37 +08:00
|
|
|
#include <linux/random.h>
|
2018-08-09 23:55:20 +08:00
|
|
|
#include <uapi/linux/btf.h>
|
bpf: pre-allocate hash map elements
If kprobe is placed on spin_unlock then calling kmalloc/kfree from
bpf programs is not safe, since the following dead lock is possible:
kfree->spin_lock(kmem_cache_node->lock)...spin_unlock->kprobe->
bpf_prog->map_update->kmalloc->spin_lock(of the same kmem_cache_node->lock)
and deadlocks.
The following solutions were considered and some implemented, but
eventually discarded
- kmem_cache_create for every map
- add recursion check to slow-path of slub
- use reserved memory in bpf_map_update for in_irq or in preempt_disabled
- kmalloc via irq_work
At the end pre-allocation of all map elements turned out to be the simplest
solution and since the user is charged upfront for all the memory, such
pre-allocation doesn't affect the user space visible behavior.
Since it's impossible to tell whether kprobe is triggered in a safe
location from kmalloc point of view, use pre-allocation by default
and introduce new BPF_F_NO_PREALLOC flag.
While testing of per-cpu hash maps it was discovered
that alloc_percpu(GFP_ATOMIC) has odd corner cases and often
fails to allocate memory even when 90% of it is free.
The pre-allocation of per-cpu hash elements solves this problem as well.
Turned out that bpf_map_update() quickly followed by
bpf_map_lookup()+bpf_map_delete() is very common pattern used
in many of iovisor/bcc/tools, so there is additional benefit of
pre-allocation, since such use cases are must faster.
Since all hash map elements are now pre-allocated we can remove
atomic increment of htab->count and save few more cycles.
Also add bpf_map_precharge_memlock() to check rlimit_memlock early to avoid
large malloc/free done by users who don't have sufficient limits.
Pre-allocation is done with vmalloc and alloc/free is done
via percpu_freelist. Here are performance numbers for different
pre-allocation algorithms that were implemented, but discarded
in favor of percpu_freelist:
1 cpu:
pcpu_ida 2.1M
pcpu_ida nolock 2.3M
bt 2.4M
kmalloc 1.8M
hlist+spinlock 2.3M
pcpu_freelist 2.6M
4 cpu:
pcpu_ida 1.5M
pcpu_ida nolock 1.8M
bt w/smp_align 1.7M
bt no/smp_align 1.1M
kmalloc 0.7M
hlist+spinlock 0.2M
pcpu_freelist 2.0M
8 cpu:
pcpu_ida 0.7M
bt w/smp_align 0.8M
kmalloc 0.4M
pcpu_freelist 1.5M
32 cpu:
kmalloc 0.13M
pcpu_freelist 0.49M
pcpu_ida nolock is a modified percpu_ida algorithm without
percpu_ida_cpu locks and without cross-cpu tag stealing.
It's faster than existing percpu_ida, but not as fast as pcpu_freelist.
bt is a variant of block/blk-mq-tag.c simlified and customized
for bpf use case. bt w/smp_align is using cache line for every 'long'
(similar to blk-mq-tag). bt no/smp_align allocates 'long'
bitmasks continuously to save memory. It's comparable to percpu_ida
and in some cases faster, but slower than percpu_freelist
hlist+spinlock is the simplest free list with single spinlock.
As expeceted it has very bad scaling in SMP.
kmalloc is existing implementation which is still available via
BPF_F_NO_PREALLOC flag. It's significantly slower in single cpu and
in 8 cpu setup it's 3 times slower than pre-allocation with pcpu_freelist,
but saves memory, so in cases where map->max_entries can be large
and number of map update/delete per second is low, it may make
sense to use it.
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2016-03-08 13:57:15 +08:00
|
|
|
#include "percpu_freelist.h"
|
2016-11-12 02:55:09 +08:00
|
|
|
#include "bpf_lru_list.h"
|
2017-03-23 01:00:34 +08:00
|
|
|
#include "map_in_map.h"
|
2014-11-14 09:36:45 +08:00
|
|
|
|
2017-10-19 04:00:22 +08:00
|
|
|
#define HTAB_CREATE_FLAG_MASK \
|
|
|
|
(BPF_F_NO_PREALLOC | BPF_F_NO_COMMON_LRU | BPF_F_NUMA_NODE | \
|
bpf: add program side {rd, wr}only support for maps
This work adds two new map creation flags BPF_F_RDONLY_PROG
and BPF_F_WRONLY_PROG in order to allow for read-only or
write-only BPF maps from a BPF program side.
Today we have BPF_F_RDONLY and BPF_F_WRONLY, but this only
applies to system call side, meaning the BPF program has full
read/write access to the map as usual while bpf(2) calls with
map fd can either only read or write into the map depending
on the flags. BPF_F_RDONLY_PROG and BPF_F_WRONLY_PROG allows
for the exact opposite such that verifier is going to reject
program loads if write into a read-only map or a read into a
write-only map is detected. For read-only map case also some
helpers are forbidden for programs that would alter the map
state such as map deletion, update, etc. As opposed to the two
BPF_F_RDONLY / BPF_F_WRONLY flags, BPF_F_RDONLY_PROG as well
as BPF_F_WRONLY_PROG really do correspond to the map lifetime.
We've enabled this generic map extension to various non-special
maps holding normal user data: array, hash, lru, lpm, local
storage, queue and stack. Further generic map types could be
followed up in future depending on use-case. Main use case
here is to forbid writes into .rodata map values from verifier
side.
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Martin KaFai Lau <kafai@fb.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2019-04-10 05:20:05 +08:00
|
|
|
BPF_F_ACCESS_MASK | BPF_F_ZERO_SEED)
|
2017-08-19 02:28:00 +08:00
|
|
|
|
2020-01-16 02:43:04 +08:00
|
|
|
#define BATCH_OPS(_name) \
|
|
|
|
.map_lookup_batch = \
|
|
|
|
_name##_map_lookup_batch, \
|
|
|
|
.map_lookup_and_delete_batch = \
|
|
|
|
_name##_map_lookup_and_delete_batch, \
|
|
|
|
.map_update_batch = \
|
|
|
|
generic_map_update_batch, \
|
|
|
|
.map_delete_batch = \
|
|
|
|
generic_map_delete_batch
|
|
|
|
|
2020-02-24 22:01:34 +08:00
|
|
|
/*
|
|
|
|
* The bucket lock has two protection scopes:
|
|
|
|
*
|
|
|
|
* 1) Serializing concurrent operations from BPF programs on differrent
|
|
|
|
* CPUs
|
|
|
|
*
|
|
|
|
* 2) Serializing concurrent operations from BPF programs and sys_bpf()
|
|
|
|
*
|
|
|
|
* BPF programs can execute in any context including perf, kprobes and
|
|
|
|
* tracing. As there are almost no limits where perf, kprobes and tracing
|
|
|
|
* can be invoked from the lock operations need to be protected against
|
|
|
|
* deadlocks. Deadlocks can be caused by recursion and by an invocation in
|
|
|
|
* the lock held section when functions which acquire this lock are invoked
|
|
|
|
* from sys_bpf(). BPF recursion is prevented by incrementing the per CPU
|
|
|
|
* variable bpf_prog_active, which prevents BPF programs attached to perf
|
|
|
|
* events, kprobes and tracing to be invoked before the prior invocation
|
|
|
|
* from one of these contexts completed. sys_bpf() uses the same mechanism
|
|
|
|
* by pinning the task to the current CPU and incrementing the recursion
|
|
|
|
* protection accross the map operation.
|
2020-02-24 22:01:51 +08:00
|
|
|
*
|
|
|
|
* This has subtle implications on PREEMPT_RT. PREEMPT_RT forbids certain
|
|
|
|
* operations like memory allocations (even with GFP_ATOMIC) from atomic
|
|
|
|
* contexts. This is required because even with GFP_ATOMIC the memory
|
|
|
|
* allocator calls into code pathes which acquire locks with long held lock
|
|
|
|
* sections. To ensure the deterministic behaviour these locks are regular
|
|
|
|
* spinlocks, which are converted to 'sleepable' spinlocks on RT. The only
|
|
|
|
* true atomic contexts on an RT kernel are the low level hardware
|
|
|
|
* handling, scheduling, low level interrupt handling, NMIs etc. None of
|
|
|
|
* these contexts should ever do memory allocations.
|
|
|
|
*
|
|
|
|
* As regular device interrupt handlers and soft interrupts are forced into
|
|
|
|
* thread context, the existing code which does
|
|
|
|
* spin_lock*(); alloc(GPF_ATOMIC); spin_unlock*();
|
|
|
|
* just works.
|
|
|
|
*
|
|
|
|
* In theory the BPF locks could be converted to regular spinlocks as well,
|
|
|
|
* but the bucket locks and percpu_freelist locks can be taken from
|
|
|
|
* arbitrary contexts (perf, kprobes, tracepoints) which are required to be
|
|
|
|
* atomic contexts even on RT. These mechanisms require preallocated maps,
|
|
|
|
* so there is no need to invoke memory allocations within the lock held
|
|
|
|
* sections.
|
|
|
|
*
|
|
|
|
* BPF maps which need dynamic allocation are only used from (forced)
|
|
|
|
* thread context on RT and can therefore use regular spinlocks which in
|
|
|
|
* turn allows to invoke memory allocations from the lock held section.
|
|
|
|
*
|
|
|
|
* On a non RT kernel this distinction is neither possible nor required.
|
|
|
|
* spinlock maps to raw_spinlock and the extra code is optimized out by the
|
|
|
|
* compiler.
|
2020-02-24 22:01:34 +08:00
|
|
|
*/
|
2015-12-29 22:40:27 +08:00
|
|
|
struct bucket {
|
2017-03-08 12:00:13 +08:00
|
|
|
struct hlist_nulls_head head;
|
2020-02-24 22:01:51 +08:00
|
|
|
union {
|
|
|
|
raw_spinlock_t raw_lock;
|
|
|
|
spinlock_t lock;
|
|
|
|
};
|
2015-12-29 22:40:27 +08:00
|
|
|
};
|
|
|
|
|
2014-11-14 09:36:45 +08:00
|
|
|
struct bpf_htab {
|
|
|
|
struct bpf_map map;
|
2015-12-29 22:40:27 +08:00
|
|
|
struct bucket *buckets;
|
bpf: pre-allocate hash map elements
If kprobe is placed on spin_unlock then calling kmalloc/kfree from
bpf programs is not safe, since the following dead lock is possible:
kfree->spin_lock(kmem_cache_node->lock)...spin_unlock->kprobe->
bpf_prog->map_update->kmalloc->spin_lock(of the same kmem_cache_node->lock)
and deadlocks.
The following solutions were considered and some implemented, but
eventually discarded
- kmem_cache_create for every map
- add recursion check to slow-path of slub
- use reserved memory in bpf_map_update for in_irq or in preempt_disabled
- kmalloc via irq_work
At the end pre-allocation of all map elements turned out to be the simplest
solution and since the user is charged upfront for all the memory, such
pre-allocation doesn't affect the user space visible behavior.
Since it's impossible to tell whether kprobe is triggered in a safe
location from kmalloc point of view, use pre-allocation by default
and introduce new BPF_F_NO_PREALLOC flag.
While testing of per-cpu hash maps it was discovered
that alloc_percpu(GFP_ATOMIC) has odd corner cases and often
fails to allocate memory even when 90% of it is free.
The pre-allocation of per-cpu hash elements solves this problem as well.
Turned out that bpf_map_update() quickly followed by
bpf_map_lookup()+bpf_map_delete() is very common pattern used
in many of iovisor/bcc/tools, so there is additional benefit of
pre-allocation, since such use cases are must faster.
Since all hash map elements are now pre-allocated we can remove
atomic increment of htab->count and save few more cycles.
Also add bpf_map_precharge_memlock() to check rlimit_memlock early to avoid
large malloc/free done by users who don't have sufficient limits.
Pre-allocation is done with vmalloc and alloc/free is done
via percpu_freelist. Here are performance numbers for different
pre-allocation algorithms that were implemented, but discarded
in favor of percpu_freelist:
1 cpu:
pcpu_ida 2.1M
pcpu_ida nolock 2.3M
bt 2.4M
kmalloc 1.8M
hlist+spinlock 2.3M
pcpu_freelist 2.6M
4 cpu:
pcpu_ida 1.5M
pcpu_ida nolock 1.8M
bt w/smp_align 1.7M
bt no/smp_align 1.1M
kmalloc 0.7M
hlist+spinlock 0.2M
pcpu_freelist 2.0M
8 cpu:
pcpu_ida 0.7M
bt w/smp_align 0.8M
kmalloc 0.4M
pcpu_freelist 1.5M
32 cpu:
kmalloc 0.13M
pcpu_freelist 0.49M
pcpu_ida nolock is a modified percpu_ida algorithm without
percpu_ida_cpu locks and without cross-cpu tag stealing.
It's faster than existing percpu_ida, but not as fast as pcpu_freelist.
bt is a variant of block/blk-mq-tag.c simlified and customized
for bpf use case. bt w/smp_align is using cache line for every 'long'
(similar to blk-mq-tag). bt no/smp_align allocates 'long'
bitmasks continuously to save memory. It's comparable to percpu_ida
and in some cases faster, but slower than percpu_freelist
hlist+spinlock is the simplest free list with single spinlock.
As expeceted it has very bad scaling in SMP.
kmalloc is existing implementation which is still available via
BPF_F_NO_PREALLOC flag. It's significantly slower in single cpu and
in 8 cpu setup it's 3 times slower than pre-allocation with pcpu_freelist,
but saves memory, so in cases where map->max_entries can be large
and number of map update/delete per second is low, it may make
sense to use it.
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2016-03-08 13:57:15 +08:00
|
|
|
void *elems;
|
2016-11-12 02:55:09 +08:00
|
|
|
union {
|
|
|
|
struct pcpu_freelist freelist;
|
|
|
|
struct bpf_lru lru;
|
|
|
|
};
|
2017-03-22 10:05:04 +08:00
|
|
|
struct htab_elem *__percpu *extra_elems;
|
2015-12-29 22:40:25 +08:00
|
|
|
atomic_t count; /* number of elements in this hashtable */
|
2014-11-14 09:36:45 +08:00
|
|
|
u32 n_buckets; /* number of hash buckets */
|
|
|
|
u32 elem_size; /* size of each element in bytes */
|
2018-08-23 05:49:37 +08:00
|
|
|
u32 hashrnd;
|
2014-11-14 09:36:45 +08:00
|
|
|
};
|
|
|
|
|
|
|
|
/* each htab element is struct htab_elem + key + value */
|
|
|
|
struct htab_elem {
|
2016-02-02 14:39:53 +08:00
|
|
|
union {
|
2017-03-08 12:00:13 +08:00
|
|
|
struct hlist_nulls_node hash_node;
|
2017-03-08 12:00:12 +08:00
|
|
|
struct {
|
|
|
|
void *padding;
|
|
|
|
union {
|
|
|
|
struct bpf_htab *htab;
|
|
|
|
struct pcpu_freelist_node fnode;
|
2020-02-20 07:47:57 +08:00
|
|
|
struct htab_elem *batch_flink;
|
2017-03-08 12:00:12 +08:00
|
|
|
};
|
|
|
|
};
|
2016-02-02 14:39:53 +08:00
|
|
|
};
|
2016-08-06 05:01:27 +08:00
|
|
|
union {
|
|
|
|
struct rcu_head rcu;
|
2016-11-12 02:55:09 +08:00
|
|
|
struct bpf_lru_node lru_node;
|
2016-08-06 05:01:27 +08:00
|
|
|
};
|
bpf: pre-allocate hash map elements
If kprobe is placed on spin_unlock then calling kmalloc/kfree from
bpf programs is not safe, since the following dead lock is possible:
kfree->spin_lock(kmem_cache_node->lock)...spin_unlock->kprobe->
bpf_prog->map_update->kmalloc->spin_lock(of the same kmem_cache_node->lock)
and deadlocks.
The following solutions were considered and some implemented, but
eventually discarded
- kmem_cache_create for every map
- add recursion check to slow-path of slub
- use reserved memory in bpf_map_update for in_irq or in preempt_disabled
- kmalloc via irq_work
At the end pre-allocation of all map elements turned out to be the simplest
solution and since the user is charged upfront for all the memory, such
pre-allocation doesn't affect the user space visible behavior.
Since it's impossible to tell whether kprobe is triggered in a safe
location from kmalloc point of view, use pre-allocation by default
and introduce new BPF_F_NO_PREALLOC flag.
While testing of per-cpu hash maps it was discovered
that alloc_percpu(GFP_ATOMIC) has odd corner cases and often
fails to allocate memory even when 90% of it is free.
The pre-allocation of per-cpu hash elements solves this problem as well.
Turned out that bpf_map_update() quickly followed by
bpf_map_lookup()+bpf_map_delete() is very common pattern used
in many of iovisor/bcc/tools, so there is additional benefit of
pre-allocation, since such use cases are must faster.
Since all hash map elements are now pre-allocated we can remove
atomic increment of htab->count and save few more cycles.
Also add bpf_map_precharge_memlock() to check rlimit_memlock early to avoid
large malloc/free done by users who don't have sufficient limits.
Pre-allocation is done with vmalloc and alloc/free is done
via percpu_freelist. Here are performance numbers for different
pre-allocation algorithms that were implemented, but discarded
in favor of percpu_freelist:
1 cpu:
pcpu_ida 2.1M
pcpu_ida nolock 2.3M
bt 2.4M
kmalloc 1.8M
hlist+spinlock 2.3M
pcpu_freelist 2.6M
4 cpu:
pcpu_ida 1.5M
pcpu_ida nolock 1.8M
bt w/smp_align 1.7M
bt no/smp_align 1.1M
kmalloc 0.7M
hlist+spinlock 0.2M
pcpu_freelist 2.0M
8 cpu:
pcpu_ida 0.7M
bt w/smp_align 0.8M
kmalloc 0.4M
pcpu_freelist 1.5M
32 cpu:
kmalloc 0.13M
pcpu_freelist 0.49M
pcpu_ida nolock is a modified percpu_ida algorithm without
percpu_ida_cpu locks and without cross-cpu tag stealing.
It's faster than existing percpu_ida, but not as fast as pcpu_freelist.
bt is a variant of block/blk-mq-tag.c simlified and customized
for bpf use case. bt w/smp_align is using cache line for every 'long'
(similar to blk-mq-tag). bt no/smp_align allocates 'long'
bitmasks continuously to save memory. It's comparable to percpu_ida
and in some cases faster, but slower than percpu_freelist
hlist+spinlock is the simplest free list with single spinlock.
As expeceted it has very bad scaling in SMP.
kmalloc is existing implementation which is still available via
BPF_F_NO_PREALLOC flag. It's significantly slower in single cpu and
in 8 cpu setup it's 3 times slower than pre-allocation with pcpu_freelist,
but saves memory, so in cases where map->max_entries can be large
and number of map update/delete per second is low, it may make
sense to use it.
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2016-03-08 13:57:15 +08:00
|
|
|
u32 hash;
|
2020-02-27 08:17:44 +08:00
|
|
|
char key[] __aligned(8);
|
2014-11-14 09:36:45 +08:00
|
|
|
};
|
|
|
|
|
2020-02-24 22:01:51 +08:00
|
|
|
static inline bool htab_is_prealloc(const struct bpf_htab *htab)
|
|
|
|
{
|
|
|
|
return !(htab->map.map_flags & BPF_F_NO_PREALLOC);
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline bool htab_use_raw_lock(const struct bpf_htab *htab)
|
|
|
|
{
|
|
|
|
return (!IS_ENABLED(CONFIG_PREEMPT_RT) || htab_is_prealloc(htab));
|
|
|
|
}
|
|
|
|
|
2020-02-24 22:01:50 +08:00
|
|
|
static void htab_init_buckets(struct bpf_htab *htab)
|
|
|
|
{
|
|
|
|
unsigned i;
|
|
|
|
|
|
|
|
for (i = 0; i < htab->n_buckets; i++) {
|
|
|
|
INIT_HLIST_NULLS_HEAD(&htab->buckets[i].head, i);
|
2020-02-24 22:01:51 +08:00
|
|
|
if (htab_use_raw_lock(htab))
|
|
|
|
raw_spin_lock_init(&htab->buckets[i].raw_lock);
|
|
|
|
else
|
|
|
|
spin_lock_init(&htab->buckets[i].lock);
|
2020-02-24 22:01:50 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline unsigned long htab_lock_bucket(const struct bpf_htab *htab,
|
|
|
|
struct bucket *b)
|
|
|
|
{
|
|
|
|
unsigned long flags;
|
|
|
|
|
2020-02-24 22:01:51 +08:00
|
|
|
if (htab_use_raw_lock(htab))
|
|
|
|
raw_spin_lock_irqsave(&b->raw_lock, flags);
|
|
|
|
else
|
|
|
|
spin_lock_irqsave(&b->lock, flags);
|
2020-02-24 22:01:50 +08:00
|
|
|
return flags;
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline void htab_unlock_bucket(const struct bpf_htab *htab,
|
|
|
|
struct bucket *b,
|
|
|
|
unsigned long flags)
|
|
|
|
{
|
2020-02-24 22:01:51 +08:00
|
|
|
if (htab_use_raw_lock(htab))
|
|
|
|
raw_spin_unlock_irqrestore(&b->raw_lock, flags);
|
|
|
|
else
|
|
|
|
spin_unlock_irqrestore(&b->lock, flags);
|
2020-02-24 22:01:50 +08:00
|
|
|
}
|
|
|
|
|
2016-11-12 02:55:09 +08:00
|
|
|
static bool htab_lru_map_delete_node(void *arg, struct bpf_lru_node *node);
|
|
|
|
|
|
|
|
static bool htab_is_lru(const struct bpf_htab *htab)
|
|
|
|
{
|
2016-11-12 02:55:10 +08:00
|
|
|
return htab->map.map_type == BPF_MAP_TYPE_LRU_HASH ||
|
|
|
|
htab->map.map_type == BPF_MAP_TYPE_LRU_PERCPU_HASH;
|
|
|
|
}
|
|
|
|
|
|
|
|
static bool htab_is_percpu(const struct bpf_htab *htab)
|
|
|
|
{
|
|
|
|
return htab->map.map_type == BPF_MAP_TYPE_PERCPU_HASH ||
|
|
|
|
htab->map.map_type == BPF_MAP_TYPE_LRU_PERCPU_HASH;
|
2016-11-12 02:55:09 +08:00
|
|
|
}
|
|
|
|
|
bpf: pre-allocate hash map elements
If kprobe is placed on spin_unlock then calling kmalloc/kfree from
bpf programs is not safe, since the following dead lock is possible:
kfree->spin_lock(kmem_cache_node->lock)...spin_unlock->kprobe->
bpf_prog->map_update->kmalloc->spin_lock(of the same kmem_cache_node->lock)
and deadlocks.
The following solutions were considered and some implemented, but
eventually discarded
- kmem_cache_create for every map
- add recursion check to slow-path of slub
- use reserved memory in bpf_map_update for in_irq or in preempt_disabled
- kmalloc via irq_work
At the end pre-allocation of all map elements turned out to be the simplest
solution and since the user is charged upfront for all the memory, such
pre-allocation doesn't affect the user space visible behavior.
Since it's impossible to tell whether kprobe is triggered in a safe
location from kmalloc point of view, use pre-allocation by default
and introduce new BPF_F_NO_PREALLOC flag.
While testing of per-cpu hash maps it was discovered
that alloc_percpu(GFP_ATOMIC) has odd corner cases and often
fails to allocate memory even when 90% of it is free.
The pre-allocation of per-cpu hash elements solves this problem as well.
Turned out that bpf_map_update() quickly followed by
bpf_map_lookup()+bpf_map_delete() is very common pattern used
in many of iovisor/bcc/tools, so there is additional benefit of
pre-allocation, since such use cases are must faster.
Since all hash map elements are now pre-allocated we can remove
atomic increment of htab->count and save few more cycles.
Also add bpf_map_precharge_memlock() to check rlimit_memlock early to avoid
large malloc/free done by users who don't have sufficient limits.
Pre-allocation is done with vmalloc and alloc/free is done
via percpu_freelist. Here are performance numbers for different
pre-allocation algorithms that were implemented, but discarded
in favor of percpu_freelist:
1 cpu:
pcpu_ida 2.1M
pcpu_ida nolock 2.3M
bt 2.4M
kmalloc 1.8M
hlist+spinlock 2.3M
pcpu_freelist 2.6M
4 cpu:
pcpu_ida 1.5M
pcpu_ida nolock 1.8M
bt w/smp_align 1.7M
bt no/smp_align 1.1M
kmalloc 0.7M
hlist+spinlock 0.2M
pcpu_freelist 2.0M
8 cpu:
pcpu_ida 0.7M
bt w/smp_align 0.8M
kmalloc 0.4M
pcpu_freelist 1.5M
32 cpu:
kmalloc 0.13M
pcpu_freelist 0.49M
pcpu_ida nolock is a modified percpu_ida algorithm without
percpu_ida_cpu locks and without cross-cpu tag stealing.
It's faster than existing percpu_ida, but not as fast as pcpu_freelist.
bt is a variant of block/blk-mq-tag.c simlified and customized
for bpf use case. bt w/smp_align is using cache line for every 'long'
(similar to blk-mq-tag). bt no/smp_align allocates 'long'
bitmasks continuously to save memory. It's comparable to percpu_ida
and in some cases faster, but slower than percpu_freelist
hlist+spinlock is the simplest free list with single spinlock.
As expeceted it has very bad scaling in SMP.
kmalloc is existing implementation which is still available via
BPF_F_NO_PREALLOC flag. It's significantly slower in single cpu and
in 8 cpu setup it's 3 times slower than pre-allocation with pcpu_freelist,
but saves memory, so in cases where map->max_entries can be large
and number of map update/delete per second is low, it may make
sense to use it.
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2016-03-08 13:57:15 +08:00
|
|
|
static inline void htab_elem_set_ptr(struct htab_elem *l, u32 key_size,
|
|
|
|
void __percpu *pptr)
|
|
|
|
{
|
|
|
|
*(void __percpu **)(l->key + key_size) = pptr;
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline void __percpu *htab_elem_get_ptr(struct htab_elem *l, u32 key_size)
|
|
|
|
{
|
|
|
|
return *(void __percpu **)(l->key + key_size);
|
|
|
|
}
|
|
|
|
|
2017-03-23 01:00:34 +08:00
|
|
|
static void *fd_htab_map_get_ptr(const struct bpf_map *map, struct htab_elem *l)
|
|
|
|
{
|
|
|
|
return *(void **)(l->key + roundup(map->key_size, 8));
|
|
|
|
}
|
|
|
|
|
bpf: pre-allocate hash map elements
If kprobe is placed on spin_unlock then calling kmalloc/kfree from
bpf programs is not safe, since the following dead lock is possible:
kfree->spin_lock(kmem_cache_node->lock)...spin_unlock->kprobe->
bpf_prog->map_update->kmalloc->spin_lock(of the same kmem_cache_node->lock)
and deadlocks.
The following solutions were considered and some implemented, but
eventually discarded
- kmem_cache_create for every map
- add recursion check to slow-path of slub
- use reserved memory in bpf_map_update for in_irq or in preempt_disabled
- kmalloc via irq_work
At the end pre-allocation of all map elements turned out to be the simplest
solution and since the user is charged upfront for all the memory, such
pre-allocation doesn't affect the user space visible behavior.
Since it's impossible to tell whether kprobe is triggered in a safe
location from kmalloc point of view, use pre-allocation by default
and introduce new BPF_F_NO_PREALLOC flag.
While testing of per-cpu hash maps it was discovered
that alloc_percpu(GFP_ATOMIC) has odd corner cases and often
fails to allocate memory even when 90% of it is free.
The pre-allocation of per-cpu hash elements solves this problem as well.
Turned out that bpf_map_update() quickly followed by
bpf_map_lookup()+bpf_map_delete() is very common pattern used
in many of iovisor/bcc/tools, so there is additional benefit of
pre-allocation, since such use cases are must faster.
Since all hash map elements are now pre-allocated we can remove
atomic increment of htab->count and save few more cycles.
Also add bpf_map_precharge_memlock() to check rlimit_memlock early to avoid
large malloc/free done by users who don't have sufficient limits.
Pre-allocation is done with vmalloc and alloc/free is done
via percpu_freelist. Here are performance numbers for different
pre-allocation algorithms that were implemented, but discarded
in favor of percpu_freelist:
1 cpu:
pcpu_ida 2.1M
pcpu_ida nolock 2.3M
bt 2.4M
kmalloc 1.8M
hlist+spinlock 2.3M
pcpu_freelist 2.6M
4 cpu:
pcpu_ida 1.5M
pcpu_ida nolock 1.8M
bt w/smp_align 1.7M
bt no/smp_align 1.1M
kmalloc 0.7M
hlist+spinlock 0.2M
pcpu_freelist 2.0M
8 cpu:
pcpu_ida 0.7M
bt w/smp_align 0.8M
kmalloc 0.4M
pcpu_freelist 1.5M
32 cpu:
kmalloc 0.13M
pcpu_freelist 0.49M
pcpu_ida nolock is a modified percpu_ida algorithm without
percpu_ida_cpu locks and without cross-cpu tag stealing.
It's faster than existing percpu_ida, but not as fast as pcpu_freelist.
bt is a variant of block/blk-mq-tag.c simlified and customized
for bpf use case. bt w/smp_align is using cache line for every 'long'
(similar to blk-mq-tag). bt no/smp_align allocates 'long'
bitmasks continuously to save memory. It's comparable to percpu_ida
and in some cases faster, but slower than percpu_freelist
hlist+spinlock is the simplest free list with single spinlock.
As expeceted it has very bad scaling in SMP.
kmalloc is existing implementation which is still available via
BPF_F_NO_PREALLOC flag. It's significantly slower in single cpu and
in 8 cpu setup it's 3 times slower than pre-allocation with pcpu_freelist,
but saves memory, so in cases where map->max_entries can be large
and number of map update/delete per second is low, it may make
sense to use it.
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2016-03-08 13:57:15 +08:00
|
|
|
static struct htab_elem *get_htab_elem(struct bpf_htab *htab, int i)
|
|
|
|
{
|
|
|
|
return (struct htab_elem *) (htab->elems + i * htab->elem_size);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void htab_free_elems(struct bpf_htab *htab)
|
|
|
|
{
|
|
|
|
int i;
|
|
|
|
|
2016-11-12 02:55:10 +08:00
|
|
|
if (!htab_is_percpu(htab))
|
bpf: pre-allocate hash map elements
If kprobe is placed on spin_unlock then calling kmalloc/kfree from
bpf programs is not safe, since the following dead lock is possible:
kfree->spin_lock(kmem_cache_node->lock)...spin_unlock->kprobe->
bpf_prog->map_update->kmalloc->spin_lock(of the same kmem_cache_node->lock)
and deadlocks.
The following solutions were considered and some implemented, but
eventually discarded
- kmem_cache_create for every map
- add recursion check to slow-path of slub
- use reserved memory in bpf_map_update for in_irq or in preempt_disabled
- kmalloc via irq_work
At the end pre-allocation of all map elements turned out to be the simplest
solution and since the user is charged upfront for all the memory, such
pre-allocation doesn't affect the user space visible behavior.
Since it's impossible to tell whether kprobe is triggered in a safe
location from kmalloc point of view, use pre-allocation by default
and introduce new BPF_F_NO_PREALLOC flag.
While testing of per-cpu hash maps it was discovered
that alloc_percpu(GFP_ATOMIC) has odd corner cases and often
fails to allocate memory even when 90% of it is free.
The pre-allocation of per-cpu hash elements solves this problem as well.
Turned out that bpf_map_update() quickly followed by
bpf_map_lookup()+bpf_map_delete() is very common pattern used
in many of iovisor/bcc/tools, so there is additional benefit of
pre-allocation, since such use cases are must faster.
Since all hash map elements are now pre-allocated we can remove
atomic increment of htab->count and save few more cycles.
Also add bpf_map_precharge_memlock() to check rlimit_memlock early to avoid
large malloc/free done by users who don't have sufficient limits.
Pre-allocation is done with vmalloc and alloc/free is done
via percpu_freelist. Here are performance numbers for different
pre-allocation algorithms that were implemented, but discarded
in favor of percpu_freelist:
1 cpu:
pcpu_ida 2.1M
pcpu_ida nolock 2.3M
bt 2.4M
kmalloc 1.8M
hlist+spinlock 2.3M
pcpu_freelist 2.6M
4 cpu:
pcpu_ida 1.5M
pcpu_ida nolock 1.8M
bt w/smp_align 1.7M
bt no/smp_align 1.1M
kmalloc 0.7M
hlist+spinlock 0.2M
pcpu_freelist 2.0M
8 cpu:
pcpu_ida 0.7M
bt w/smp_align 0.8M
kmalloc 0.4M
pcpu_freelist 1.5M
32 cpu:
kmalloc 0.13M
pcpu_freelist 0.49M
pcpu_ida nolock is a modified percpu_ida algorithm without
percpu_ida_cpu locks and without cross-cpu tag stealing.
It's faster than existing percpu_ida, but not as fast as pcpu_freelist.
bt is a variant of block/blk-mq-tag.c simlified and customized
for bpf use case. bt w/smp_align is using cache line for every 'long'
(similar to blk-mq-tag). bt no/smp_align allocates 'long'
bitmasks continuously to save memory. It's comparable to percpu_ida
and in some cases faster, but slower than percpu_freelist
hlist+spinlock is the simplest free list with single spinlock.
As expeceted it has very bad scaling in SMP.
kmalloc is existing implementation which is still available via
BPF_F_NO_PREALLOC flag. It's significantly slower in single cpu and
in 8 cpu setup it's 3 times slower than pre-allocation with pcpu_freelist,
but saves memory, so in cases where map->max_entries can be large
and number of map update/delete per second is low, it may make
sense to use it.
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2016-03-08 13:57:15 +08:00
|
|
|
goto free_elems;
|
|
|
|
|
|
|
|
for (i = 0; i < htab->map.max_entries; i++) {
|
|
|
|
void __percpu *pptr;
|
|
|
|
|
|
|
|
pptr = htab_elem_get_ptr(get_htab_elem(htab, i),
|
|
|
|
htab->map.key_size);
|
|
|
|
free_percpu(pptr);
|
2017-12-13 06:22:39 +08:00
|
|
|
cond_resched();
|
bpf: pre-allocate hash map elements
If kprobe is placed on spin_unlock then calling kmalloc/kfree from
bpf programs is not safe, since the following dead lock is possible:
kfree->spin_lock(kmem_cache_node->lock)...spin_unlock->kprobe->
bpf_prog->map_update->kmalloc->spin_lock(of the same kmem_cache_node->lock)
and deadlocks.
The following solutions were considered and some implemented, but
eventually discarded
- kmem_cache_create for every map
- add recursion check to slow-path of slub
- use reserved memory in bpf_map_update for in_irq or in preempt_disabled
- kmalloc via irq_work
At the end pre-allocation of all map elements turned out to be the simplest
solution and since the user is charged upfront for all the memory, such
pre-allocation doesn't affect the user space visible behavior.
Since it's impossible to tell whether kprobe is triggered in a safe
location from kmalloc point of view, use pre-allocation by default
and introduce new BPF_F_NO_PREALLOC flag.
While testing of per-cpu hash maps it was discovered
that alloc_percpu(GFP_ATOMIC) has odd corner cases and often
fails to allocate memory even when 90% of it is free.
The pre-allocation of per-cpu hash elements solves this problem as well.
Turned out that bpf_map_update() quickly followed by
bpf_map_lookup()+bpf_map_delete() is very common pattern used
in many of iovisor/bcc/tools, so there is additional benefit of
pre-allocation, since such use cases are must faster.
Since all hash map elements are now pre-allocated we can remove
atomic increment of htab->count and save few more cycles.
Also add bpf_map_precharge_memlock() to check rlimit_memlock early to avoid
large malloc/free done by users who don't have sufficient limits.
Pre-allocation is done with vmalloc and alloc/free is done
via percpu_freelist. Here are performance numbers for different
pre-allocation algorithms that were implemented, but discarded
in favor of percpu_freelist:
1 cpu:
pcpu_ida 2.1M
pcpu_ida nolock 2.3M
bt 2.4M
kmalloc 1.8M
hlist+spinlock 2.3M
pcpu_freelist 2.6M
4 cpu:
pcpu_ida 1.5M
pcpu_ida nolock 1.8M
bt w/smp_align 1.7M
bt no/smp_align 1.1M
kmalloc 0.7M
hlist+spinlock 0.2M
pcpu_freelist 2.0M
8 cpu:
pcpu_ida 0.7M
bt w/smp_align 0.8M
kmalloc 0.4M
pcpu_freelist 1.5M
32 cpu:
kmalloc 0.13M
pcpu_freelist 0.49M
pcpu_ida nolock is a modified percpu_ida algorithm without
percpu_ida_cpu locks and without cross-cpu tag stealing.
It's faster than existing percpu_ida, but not as fast as pcpu_freelist.
bt is a variant of block/blk-mq-tag.c simlified and customized
for bpf use case. bt w/smp_align is using cache line for every 'long'
(similar to blk-mq-tag). bt no/smp_align allocates 'long'
bitmasks continuously to save memory. It's comparable to percpu_ida
and in some cases faster, but slower than percpu_freelist
hlist+spinlock is the simplest free list with single spinlock.
As expeceted it has very bad scaling in SMP.
kmalloc is existing implementation which is still available via
BPF_F_NO_PREALLOC flag. It's significantly slower in single cpu and
in 8 cpu setup it's 3 times slower than pre-allocation with pcpu_freelist,
but saves memory, so in cases where map->max_entries can be large
and number of map update/delete per second is low, it may make
sense to use it.
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2016-03-08 13:57:15 +08:00
|
|
|
}
|
|
|
|
free_elems:
|
bpf: don't trigger OOM killer under pressure with map alloc
This patch adds two helpers, bpf_map_area_alloc() and bpf_map_area_free(),
that are to be used for map allocations. Using kmalloc() for very large
allocations can cause excessive work within the page allocator, so i) fall
back earlier to vmalloc() when the attempt is considered costly anyway,
and even more importantly ii) don't trigger OOM killer with any of the
allocators.
Since this is based on a user space request, for example, when creating
maps with element pre-allocation, we really want such requests to fail
instead of killing other user space processes.
Also, don't spam the kernel log with warnings should any of the allocations
fail under pressure. Given that, we can make backend selection in
bpf_map_area_alloc() generic, and convert all maps over to use this API
for spots with potentially large allocation requests.
Note, replacing the one kmalloc_array() is fine as overflow checks happen
earlier in htab_map_alloc(), since it must also protect the multiplication
for vmalloc() should kmalloc_array() fail.
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-01-18 22:14:17 +08:00
|
|
|
bpf_map_area_free(htab->elems);
|
bpf: pre-allocate hash map elements
If kprobe is placed on spin_unlock then calling kmalloc/kfree from
bpf programs is not safe, since the following dead lock is possible:
kfree->spin_lock(kmem_cache_node->lock)...spin_unlock->kprobe->
bpf_prog->map_update->kmalloc->spin_lock(of the same kmem_cache_node->lock)
and deadlocks.
The following solutions were considered and some implemented, but
eventually discarded
- kmem_cache_create for every map
- add recursion check to slow-path of slub
- use reserved memory in bpf_map_update for in_irq or in preempt_disabled
- kmalloc via irq_work
At the end pre-allocation of all map elements turned out to be the simplest
solution and since the user is charged upfront for all the memory, such
pre-allocation doesn't affect the user space visible behavior.
Since it's impossible to tell whether kprobe is triggered in a safe
location from kmalloc point of view, use pre-allocation by default
and introduce new BPF_F_NO_PREALLOC flag.
While testing of per-cpu hash maps it was discovered
that alloc_percpu(GFP_ATOMIC) has odd corner cases and often
fails to allocate memory even when 90% of it is free.
The pre-allocation of per-cpu hash elements solves this problem as well.
Turned out that bpf_map_update() quickly followed by
bpf_map_lookup()+bpf_map_delete() is very common pattern used
in many of iovisor/bcc/tools, so there is additional benefit of
pre-allocation, since such use cases are must faster.
Since all hash map elements are now pre-allocated we can remove
atomic increment of htab->count and save few more cycles.
Also add bpf_map_precharge_memlock() to check rlimit_memlock early to avoid
large malloc/free done by users who don't have sufficient limits.
Pre-allocation is done with vmalloc and alloc/free is done
via percpu_freelist. Here are performance numbers for different
pre-allocation algorithms that were implemented, but discarded
in favor of percpu_freelist:
1 cpu:
pcpu_ida 2.1M
pcpu_ida nolock 2.3M
bt 2.4M
kmalloc 1.8M
hlist+spinlock 2.3M
pcpu_freelist 2.6M
4 cpu:
pcpu_ida 1.5M
pcpu_ida nolock 1.8M
bt w/smp_align 1.7M
bt no/smp_align 1.1M
kmalloc 0.7M
hlist+spinlock 0.2M
pcpu_freelist 2.0M
8 cpu:
pcpu_ida 0.7M
bt w/smp_align 0.8M
kmalloc 0.4M
pcpu_freelist 1.5M
32 cpu:
kmalloc 0.13M
pcpu_freelist 0.49M
pcpu_ida nolock is a modified percpu_ida algorithm without
percpu_ida_cpu locks and without cross-cpu tag stealing.
It's faster than existing percpu_ida, but not as fast as pcpu_freelist.
bt is a variant of block/blk-mq-tag.c simlified and customized
for bpf use case. bt w/smp_align is using cache line for every 'long'
(similar to blk-mq-tag). bt no/smp_align allocates 'long'
bitmasks continuously to save memory. It's comparable to percpu_ida
and in some cases faster, but slower than percpu_freelist
hlist+spinlock is the simplest free list with single spinlock.
As expeceted it has very bad scaling in SMP.
kmalloc is existing implementation which is still available via
BPF_F_NO_PREALLOC flag. It's significantly slower in single cpu and
in 8 cpu setup it's 3 times slower than pre-allocation with pcpu_freelist,
but saves memory, so in cases where map->max_entries can be large
and number of map update/delete per second is low, it may make
sense to use it.
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2016-03-08 13:57:15 +08:00
|
|
|
}
|
|
|
|
|
2020-02-20 07:47:57 +08:00
|
|
|
/* The LRU list has a lock (lru_lock). Each htab bucket has a lock
|
|
|
|
* (bucket_lock). If both locks need to be acquired together, the lock
|
|
|
|
* order is always lru_lock -> bucket_lock and this only happens in
|
|
|
|
* bpf_lru_list.c logic. For example, certain code path of
|
|
|
|
* bpf_lru_pop_free(), which is called by function prealloc_lru_pop(),
|
|
|
|
* will acquire lru_lock first followed by acquiring bucket_lock.
|
|
|
|
*
|
|
|
|
* In hashtab.c, to avoid deadlock, lock acquisition of
|
|
|
|
* bucket_lock followed by lru_lock is not allowed. In such cases,
|
|
|
|
* bucket_lock needs to be released first before acquiring lru_lock.
|
|
|
|
*/
|
2016-11-12 02:55:09 +08:00
|
|
|
static struct htab_elem *prealloc_lru_pop(struct bpf_htab *htab, void *key,
|
|
|
|
u32 hash)
|
|
|
|
{
|
|
|
|
struct bpf_lru_node *node = bpf_lru_pop_free(&htab->lru, hash);
|
|
|
|
struct htab_elem *l;
|
|
|
|
|
|
|
|
if (node) {
|
|
|
|
l = container_of(node, struct htab_elem, lru_node);
|
|
|
|
memcpy(l->key, key, htab->map.key_size);
|
|
|
|
return l;
|
|
|
|
}
|
|
|
|
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int prealloc_init(struct bpf_htab *htab)
|
bpf: pre-allocate hash map elements
If kprobe is placed on spin_unlock then calling kmalloc/kfree from
bpf programs is not safe, since the following dead lock is possible:
kfree->spin_lock(kmem_cache_node->lock)...spin_unlock->kprobe->
bpf_prog->map_update->kmalloc->spin_lock(of the same kmem_cache_node->lock)
and deadlocks.
The following solutions were considered and some implemented, but
eventually discarded
- kmem_cache_create for every map
- add recursion check to slow-path of slub
- use reserved memory in bpf_map_update for in_irq or in preempt_disabled
- kmalloc via irq_work
At the end pre-allocation of all map elements turned out to be the simplest
solution and since the user is charged upfront for all the memory, such
pre-allocation doesn't affect the user space visible behavior.
Since it's impossible to tell whether kprobe is triggered in a safe
location from kmalloc point of view, use pre-allocation by default
and introduce new BPF_F_NO_PREALLOC flag.
While testing of per-cpu hash maps it was discovered
that alloc_percpu(GFP_ATOMIC) has odd corner cases and often
fails to allocate memory even when 90% of it is free.
The pre-allocation of per-cpu hash elements solves this problem as well.
Turned out that bpf_map_update() quickly followed by
bpf_map_lookup()+bpf_map_delete() is very common pattern used
in many of iovisor/bcc/tools, so there is additional benefit of
pre-allocation, since such use cases are must faster.
Since all hash map elements are now pre-allocated we can remove
atomic increment of htab->count and save few more cycles.
Also add bpf_map_precharge_memlock() to check rlimit_memlock early to avoid
large malloc/free done by users who don't have sufficient limits.
Pre-allocation is done with vmalloc and alloc/free is done
via percpu_freelist. Here are performance numbers for different
pre-allocation algorithms that were implemented, but discarded
in favor of percpu_freelist:
1 cpu:
pcpu_ida 2.1M
pcpu_ida nolock 2.3M
bt 2.4M
kmalloc 1.8M
hlist+spinlock 2.3M
pcpu_freelist 2.6M
4 cpu:
pcpu_ida 1.5M
pcpu_ida nolock 1.8M
bt w/smp_align 1.7M
bt no/smp_align 1.1M
kmalloc 0.7M
hlist+spinlock 0.2M
pcpu_freelist 2.0M
8 cpu:
pcpu_ida 0.7M
bt w/smp_align 0.8M
kmalloc 0.4M
pcpu_freelist 1.5M
32 cpu:
kmalloc 0.13M
pcpu_freelist 0.49M
pcpu_ida nolock is a modified percpu_ida algorithm without
percpu_ida_cpu locks and without cross-cpu tag stealing.
It's faster than existing percpu_ida, but not as fast as pcpu_freelist.
bt is a variant of block/blk-mq-tag.c simlified and customized
for bpf use case. bt w/smp_align is using cache line for every 'long'
(similar to blk-mq-tag). bt no/smp_align allocates 'long'
bitmasks continuously to save memory. It's comparable to percpu_ida
and in some cases faster, but slower than percpu_freelist
hlist+spinlock is the simplest free list with single spinlock.
As expeceted it has very bad scaling in SMP.
kmalloc is existing implementation which is still available via
BPF_F_NO_PREALLOC flag. It's significantly slower in single cpu and
in 8 cpu setup it's 3 times slower than pre-allocation with pcpu_freelist,
but saves memory, so in cases where map->max_entries can be large
and number of map update/delete per second is low, it may make
sense to use it.
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2016-03-08 13:57:15 +08:00
|
|
|
{
|
2017-03-22 10:05:04 +08:00
|
|
|
u32 num_entries = htab->map.max_entries;
|
bpf: pre-allocate hash map elements
If kprobe is placed on spin_unlock then calling kmalloc/kfree from
bpf programs is not safe, since the following dead lock is possible:
kfree->spin_lock(kmem_cache_node->lock)...spin_unlock->kprobe->
bpf_prog->map_update->kmalloc->spin_lock(of the same kmem_cache_node->lock)
and deadlocks.
The following solutions were considered and some implemented, but
eventually discarded
- kmem_cache_create for every map
- add recursion check to slow-path of slub
- use reserved memory in bpf_map_update for in_irq or in preempt_disabled
- kmalloc via irq_work
At the end pre-allocation of all map elements turned out to be the simplest
solution and since the user is charged upfront for all the memory, such
pre-allocation doesn't affect the user space visible behavior.
Since it's impossible to tell whether kprobe is triggered in a safe
location from kmalloc point of view, use pre-allocation by default
and introduce new BPF_F_NO_PREALLOC flag.
While testing of per-cpu hash maps it was discovered
that alloc_percpu(GFP_ATOMIC) has odd corner cases and often
fails to allocate memory even when 90% of it is free.
The pre-allocation of per-cpu hash elements solves this problem as well.
Turned out that bpf_map_update() quickly followed by
bpf_map_lookup()+bpf_map_delete() is very common pattern used
in many of iovisor/bcc/tools, so there is additional benefit of
pre-allocation, since such use cases are must faster.
Since all hash map elements are now pre-allocated we can remove
atomic increment of htab->count and save few more cycles.
Also add bpf_map_precharge_memlock() to check rlimit_memlock early to avoid
large malloc/free done by users who don't have sufficient limits.
Pre-allocation is done with vmalloc and alloc/free is done
via percpu_freelist. Here are performance numbers for different
pre-allocation algorithms that were implemented, but discarded
in favor of percpu_freelist:
1 cpu:
pcpu_ida 2.1M
pcpu_ida nolock 2.3M
bt 2.4M
kmalloc 1.8M
hlist+spinlock 2.3M
pcpu_freelist 2.6M
4 cpu:
pcpu_ida 1.5M
pcpu_ida nolock 1.8M
bt w/smp_align 1.7M
bt no/smp_align 1.1M
kmalloc 0.7M
hlist+spinlock 0.2M
pcpu_freelist 2.0M
8 cpu:
pcpu_ida 0.7M
bt w/smp_align 0.8M
kmalloc 0.4M
pcpu_freelist 1.5M
32 cpu:
kmalloc 0.13M
pcpu_freelist 0.49M
pcpu_ida nolock is a modified percpu_ida algorithm without
percpu_ida_cpu locks and without cross-cpu tag stealing.
It's faster than existing percpu_ida, but not as fast as pcpu_freelist.
bt is a variant of block/blk-mq-tag.c simlified and customized
for bpf use case. bt w/smp_align is using cache line for every 'long'
(similar to blk-mq-tag). bt no/smp_align allocates 'long'
bitmasks continuously to save memory. It's comparable to percpu_ida
and in some cases faster, but slower than percpu_freelist
hlist+spinlock is the simplest free list with single spinlock.
As expeceted it has very bad scaling in SMP.
kmalloc is existing implementation which is still available via
BPF_F_NO_PREALLOC flag. It's significantly slower in single cpu and
in 8 cpu setup it's 3 times slower than pre-allocation with pcpu_freelist,
but saves memory, so in cases where map->max_entries can be large
and number of map update/delete per second is low, it may make
sense to use it.
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2016-03-08 13:57:15 +08:00
|
|
|
int err = -ENOMEM, i;
|
|
|
|
|
2017-03-22 10:05:04 +08:00
|
|
|
if (!htab_is_percpu(htab) && !htab_is_lru(htab))
|
|
|
|
num_entries += num_possible_cpus();
|
|
|
|
|
2017-08-19 02:28:00 +08:00
|
|
|
htab->elems = bpf_map_area_alloc(htab->elem_size * num_entries,
|
|
|
|
htab->map.numa_node);
|
bpf: pre-allocate hash map elements
If kprobe is placed on spin_unlock then calling kmalloc/kfree from
bpf programs is not safe, since the following dead lock is possible:
kfree->spin_lock(kmem_cache_node->lock)...spin_unlock->kprobe->
bpf_prog->map_update->kmalloc->spin_lock(of the same kmem_cache_node->lock)
and deadlocks.
The following solutions were considered and some implemented, but
eventually discarded
- kmem_cache_create for every map
- add recursion check to slow-path of slub
- use reserved memory in bpf_map_update for in_irq or in preempt_disabled
- kmalloc via irq_work
At the end pre-allocation of all map elements turned out to be the simplest
solution and since the user is charged upfront for all the memory, such
pre-allocation doesn't affect the user space visible behavior.
Since it's impossible to tell whether kprobe is triggered in a safe
location from kmalloc point of view, use pre-allocation by default
and introduce new BPF_F_NO_PREALLOC flag.
While testing of per-cpu hash maps it was discovered
that alloc_percpu(GFP_ATOMIC) has odd corner cases and often
fails to allocate memory even when 90% of it is free.
The pre-allocation of per-cpu hash elements solves this problem as well.
Turned out that bpf_map_update() quickly followed by
bpf_map_lookup()+bpf_map_delete() is very common pattern used
in many of iovisor/bcc/tools, so there is additional benefit of
pre-allocation, since such use cases are must faster.
Since all hash map elements are now pre-allocated we can remove
atomic increment of htab->count and save few more cycles.
Also add bpf_map_precharge_memlock() to check rlimit_memlock early to avoid
large malloc/free done by users who don't have sufficient limits.
Pre-allocation is done with vmalloc and alloc/free is done
via percpu_freelist. Here are performance numbers for different
pre-allocation algorithms that were implemented, but discarded
in favor of percpu_freelist:
1 cpu:
pcpu_ida 2.1M
pcpu_ida nolock 2.3M
bt 2.4M
kmalloc 1.8M
hlist+spinlock 2.3M
pcpu_freelist 2.6M
4 cpu:
pcpu_ida 1.5M
pcpu_ida nolock 1.8M
bt w/smp_align 1.7M
bt no/smp_align 1.1M
kmalloc 0.7M
hlist+spinlock 0.2M
pcpu_freelist 2.0M
8 cpu:
pcpu_ida 0.7M
bt w/smp_align 0.8M
kmalloc 0.4M
pcpu_freelist 1.5M
32 cpu:
kmalloc 0.13M
pcpu_freelist 0.49M
pcpu_ida nolock is a modified percpu_ida algorithm without
percpu_ida_cpu locks and without cross-cpu tag stealing.
It's faster than existing percpu_ida, but not as fast as pcpu_freelist.
bt is a variant of block/blk-mq-tag.c simlified and customized
for bpf use case. bt w/smp_align is using cache line for every 'long'
(similar to blk-mq-tag). bt no/smp_align allocates 'long'
bitmasks continuously to save memory. It's comparable to percpu_ida
and in some cases faster, but slower than percpu_freelist
hlist+spinlock is the simplest free list with single spinlock.
As expeceted it has very bad scaling in SMP.
kmalloc is existing implementation which is still available via
BPF_F_NO_PREALLOC flag. It's significantly slower in single cpu and
in 8 cpu setup it's 3 times slower than pre-allocation with pcpu_freelist,
but saves memory, so in cases where map->max_entries can be large
and number of map update/delete per second is low, it may make
sense to use it.
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2016-03-08 13:57:15 +08:00
|
|
|
if (!htab->elems)
|
|
|
|
return -ENOMEM;
|
|
|
|
|
2016-11-12 02:55:10 +08:00
|
|
|
if (!htab_is_percpu(htab))
|
bpf: pre-allocate hash map elements
If kprobe is placed on spin_unlock then calling kmalloc/kfree from
bpf programs is not safe, since the following dead lock is possible:
kfree->spin_lock(kmem_cache_node->lock)...spin_unlock->kprobe->
bpf_prog->map_update->kmalloc->spin_lock(of the same kmem_cache_node->lock)
and deadlocks.
The following solutions were considered and some implemented, but
eventually discarded
- kmem_cache_create for every map
- add recursion check to slow-path of slub
- use reserved memory in bpf_map_update for in_irq or in preempt_disabled
- kmalloc via irq_work
At the end pre-allocation of all map elements turned out to be the simplest
solution and since the user is charged upfront for all the memory, such
pre-allocation doesn't affect the user space visible behavior.
Since it's impossible to tell whether kprobe is triggered in a safe
location from kmalloc point of view, use pre-allocation by default
and introduce new BPF_F_NO_PREALLOC flag.
While testing of per-cpu hash maps it was discovered
that alloc_percpu(GFP_ATOMIC) has odd corner cases and often
fails to allocate memory even when 90% of it is free.
The pre-allocation of per-cpu hash elements solves this problem as well.
Turned out that bpf_map_update() quickly followed by
bpf_map_lookup()+bpf_map_delete() is very common pattern used
in many of iovisor/bcc/tools, so there is additional benefit of
pre-allocation, since such use cases are must faster.
Since all hash map elements are now pre-allocated we can remove
atomic increment of htab->count and save few more cycles.
Also add bpf_map_precharge_memlock() to check rlimit_memlock early to avoid
large malloc/free done by users who don't have sufficient limits.
Pre-allocation is done with vmalloc and alloc/free is done
via percpu_freelist. Here are performance numbers for different
pre-allocation algorithms that were implemented, but discarded
in favor of percpu_freelist:
1 cpu:
pcpu_ida 2.1M
pcpu_ida nolock 2.3M
bt 2.4M
kmalloc 1.8M
hlist+spinlock 2.3M
pcpu_freelist 2.6M
4 cpu:
pcpu_ida 1.5M
pcpu_ida nolock 1.8M
bt w/smp_align 1.7M
bt no/smp_align 1.1M
kmalloc 0.7M
hlist+spinlock 0.2M
pcpu_freelist 2.0M
8 cpu:
pcpu_ida 0.7M
bt w/smp_align 0.8M
kmalloc 0.4M
pcpu_freelist 1.5M
32 cpu:
kmalloc 0.13M
pcpu_freelist 0.49M
pcpu_ida nolock is a modified percpu_ida algorithm without
percpu_ida_cpu locks and without cross-cpu tag stealing.
It's faster than existing percpu_ida, but not as fast as pcpu_freelist.
bt is a variant of block/blk-mq-tag.c simlified and customized
for bpf use case. bt w/smp_align is using cache line for every 'long'
(similar to blk-mq-tag). bt no/smp_align allocates 'long'
bitmasks continuously to save memory. It's comparable to percpu_ida
and in some cases faster, but slower than percpu_freelist
hlist+spinlock is the simplest free list with single spinlock.
As expeceted it has very bad scaling in SMP.
kmalloc is existing implementation which is still available via
BPF_F_NO_PREALLOC flag. It's significantly slower in single cpu and
in 8 cpu setup it's 3 times slower than pre-allocation with pcpu_freelist,
but saves memory, so in cases where map->max_entries can be large
and number of map update/delete per second is low, it may make
sense to use it.
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2016-03-08 13:57:15 +08:00
|
|
|
goto skip_percpu_elems;
|
|
|
|
|
2017-03-22 10:05:04 +08:00
|
|
|
for (i = 0; i < num_entries; i++) {
|
bpf: pre-allocate hash map elements
If kprobe is placed on spin_unlock then calling kmalloc/kfree from
bpf programs is not safe, since the following dead lock is possible:
kfree->spin_lock(kmem_cache_node->lock)...spin_unlock->kprobe->
bpf_prog->map_update->kmalloc->spin_lock(of the same kmem_cache_node->lock)
and deadlocks.
The following solutions were considered and some implemented, but
eventually discarded
- kmem_cache_create for every map
- add recursion check to slow-path of slub
- use reserved memory in bpf_map_update for in_irq or in preempt_disabled
- kmalloc via irq_work
At the end pre-allocation of all map elements turned out to be the simplest
solution and since the user is charged upfront for all the memory, such
pre-allocation doesn't affect the user space visible behavior.
Since it's impossible to tell whether kprobe is triggered in a safe
location from kmalloc point of view, use pre-allocation by default
and introduce new BPF_F_NO_PREALLOC flag.
While testing of per-cpu hash maps it was discovered
that alloc_percpu(GFP_ATOMIC) has odd corner cases and often
fails to allocate memory even when 90% of it is free.
The pre-allocation of per-cpu hash elements solves this problem as well.
Turned out that bpf_map_update() quickly followed by
bpf_map_lookup()+bpf_map_delete() is very common pattern used
in many of iovisor/bcc/tools, so there is additional benefit of
pre-allocation, since such use cases are must faster.
Since all hash map elements are now pre-allocated we can remove
atomic increment of htab->count and save few more cycles.
Also add bpf_map_precharge_memlock() to check rlimit_memlock early to avoid
large malloc/free done by users who don't have sufficient limits.
Pre-allocation is done with vmalloc and alloc/free is done
via percpu_freelist. Here are performance numbers for different
pre-allocation algorithms that were implemented, but discarded
in favor of percpu_freelist:
1 cpu:
pcpu_ida 2.1M
pcpu_ida nolock 2.3M
bt 2.4M
kmalloc 1.8M
hlist+spinlock 2.3M
pcpu_freelist 2.6M
4 cpu:
pcpu_ida 1.5M
pcpu_ida nolock 1.8M
bt w/smp_align 1.7M
bt no/smp_align 1.1M
kmalloc 0.7M
hlist+spinlock 0.2M
pcpu_freelist 2.0M
8 cpu:
pcpu_ida 0.7M
bt w/smp_align 0.8M
kmalloc 0.4M
pcpu_freelist 1.5M
32 cpu:
kmalloc 0.13M
pcpu_freelist 0.49M
pcpu_ida nolock is a modified percpu_ida algorithm without
percpu_ida_cpu locks and without cross-cpu tag stealing.
It's faster than existing percpu_ida, but not as fast as pcpu_freelist.
bt is a variant of block/blk-mq-tag.c simlified and customized
for bpf use case. bt w/smp_align is using cache line for every 'long'
(similar to blk-mq-tag). bt no/smp_align allocates 'long'
bitmasks continuously to save memory. It's comparable to percpu_ida
and in some cases faster, but slower than percpu_freelist
hlist+spinlock is the simplest free list with single spinlock.
As expeceted it has very bad scaling in SMP.
kmalloc is existing implementation which is still available via
BPF_F_NO_PREALLOC flag. It's significantly slower in single cpu and
in 8 cpu setup it's 3 times slower than pre-allocation with pcpu_freelist,
but saves memory, so in cases where map->max_entries can be large
and number of map update/delete per second is low, it may make
sense to use it.
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2016-03-08 13:57:15 +08:00
|
|
|
u32 size = round_up(htab->map.value_size, 8);
|
|
|
|
void __percpu *pptr;
|
|
|
|
|
|
|
|
pptr = __alloc_percpu_gfp(size, 8, GFP_USER | __GFP_NOWARN);
|
|
|
|
if (!pptr)
|
|
|
|
goto free_elems;
|
|
|
|
htab_elem_set_ptr(get_htab_elem(htab, i), htab->map.key_size,
|
|
|
|
pptr);
|
2017-12-13 06:22:39 +08:00
|
|
|
cond_resched();
|
bpf: pre-allocate hash map elements
If kprobe is placed on spin_unlock then calling kmalloc/kfree from
bpf programs is not safe, since the following dead lock is possible:
kfree->spin_lock(kmem_cache_node->lock)...spin_unlock->kprobe->
bpf_prog->map_update->kmalloc->spin_lock(of the same kmem_cache_node->lock)
and deadlocks.
The following solutions were considered and some implemented, but
eventually discarded
- kmem_cache_create for every map
- add recursion check to slow-path of slub
- use reserved memory in bpf_map_update for in_irq or in preempt_disabled
- kmalloc via irq_work
At the end pre-allocation of all map elements turned out to be the simplest
solution and since the user is charged upfront for all the memory, such
pre-allocation doesn't affect the user space visible behavior.
Since it's impossible to tell whether kprobe is triggered in a safe
location from kmalloc point of view, use pre-allocation by default
and introduce new BPF_F_NO_PREALLOC flag.
While testing of per-cpu hash maps it was discovered
that alloc_percpu(GFP_ATOMIC) has odd corner cases and often
fails to allocate memory even when 90% of it is free.
The pre-allocation of per-cpu hash elements solves this problem as well.
Turned out that bpf_map_update() quickly followed by
bpf_map_lookup()+bpf_map_delete() is very common pattern used
in many of iovisor/bcc/tools, so there is additional benefit of
pre-allocation, since such use cases are must faster.
Since all hash map elements are now pre-allocated we can remove
atomic increment of htab->count and save few more cycles.
Also add bpf_map_precharge_memlock() to check rlimit_memlock early to avoid
large malloc/free done by users who don't have sufficient limits.
Pre-allocation is done with vmalloc and alloc/free is done
via percpu_freelist. Here are performance numbers for different
pre-allocation algorithms that were implemented, but discarded
in favor of percpu_freelist:
1 cpu:
pcpu_ida 2.1M
pcpu_ida nolock 2.3M
bt 2.4M
kmalloc 1.8M
hlist+spinlock 2.3M
pcpu_freelist 2.6M
4 cpu:
pcpu_ida 1.5M
pcpu_ida nolock 1.8M
bt w/smp_align 1.7M
bt no/smp_align 1.1M
kmalloc 0.7M
hlist+spinlock 0.2M
pcpu_freelist 2.0M
8 cpu:
pcpu_ida 0.7M
bt w/smp_align 0.8M
kmalloc 0.4M
pcpu_freelist 1.5M
32 cpu:
kmalloc 0.13M
pcpu_freelist 0.49M
pcpu_ida nolock is a modified percpu_ida algorithm without
percpu_ida_cpu locks and without cross-cpu tag stealing.
It's faster than existing percpu_ida, but not as fast as pcpu_freelist.
bt is a variant of block/blk-mq-tag.c simlified and customized
for bpf use case. bt w/smp_align is using cache line for every 'long'
(similar to blk-mq-tag). bt no/smp_align allocates 'long'
bitmasks continuously to save memory. It's comparable to percpu_ida
and in some cases faster, but slower than percpu_freelist
hlist+spinlock is the simplest free list with single spinlock.
As expeceted it has very bad scaling in SMP.
kmalloc is existing implementation which is still available via
BPF_F_NO_PREALLOC flag. It's significantly slower in single cpu and
in 8 cpu setup it's 3 times slower than pre-allocation with pcpu_freelist,
but saves memory, so in cases where map->max_entries can be large
and number of map update/delete per second is low, it may make
sense to use it.
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2016-03-08 13:57:15 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
skip_percpu_elems:
|
2016-11-12 02:55:09 +08:00
|
|
|
if (htab_is_lru(htab))
|
|
|
|
err = bpf_lru_init(&htab->lru,
|
|
|
|
htab->map.map_flags & BPF_F_NO_COMMON_LRU,
|
|
|
|
offsetof(struct htab_elem, hash) -
|
|
|
|
offsetof(struct htab_elem, lru_node),
|
|
|
|
htab_lru_map_delete_node,
|
|
|
|
htab);
|
|
|
|
else
|
|
|
|
err = pcpu_freelist_init(&htab->freelist);
|
|
|
|
|
bpf: pre-allocate hash map elements
If kprobe is placed on spin_unlock then calling kmalloc/kfree from
bpf programs is not safe, since the following dead lock is possible:
kfree->spin_lock(kmem_cache_node->lock)...spin_unlock->kprobe->
bpf_prog->map_update->kmalloc->spin_lock(of the same kmem_cache_node->lock)
and deadlocks.
The following solutions were considered and some implemented, but
eventually discarded
- kmem_cache_create for every map
- add recursion check to slow-path of slub
- use reserved memory in bpf_map_update for in_irq or in preempt_disabled
- kmalloc via irq_work
At the end pre-allocation of all map elements turned out to be the simplest
solution and since the user is charged upfront for all the memory, such
pre-allocation doesn't affect the user space visible behavior.
Since it's impossible to tell whether kprobe is triggered in a safe
location from kmalloc point of view, use pre-allocation by default
and introduce new BPF_F_NO_PREALLOC flag.
While testing of per-cpu hash maps it was discovered
that alloc_percpu(GFP_ATOMIC) has odd corner cases and often
fails to allocate memory even when 90% of it is free.
The pre-allocation of per-cpu hash elements solves this problem as well.
Turned out that bpf_map_update() quickly followed by
bpf_map_lookup()+bpf_map_delete() is very common pattern used
in many of iovisor/bcc/tools, so there is additional benefit of
pre-allocation, since such use cases are must faster.
Since all hash map elements are now pre-allocated we can remove
atomic increment of htab->count and save few more cycles.
Also add bpf_map_precharge_memlock() to check rlimit_memlock early to avoid
large malloc/free done by users who don't have sufficient limits.
Pre-allocation is done with vmalloc and alloc/free is done
via percpu_freelist. Here are performance numbers for different
pre-allocation algorithms that were implemented, but discarded
in favor of percpu_freelist:
1 cpu:
pcpu_ida 2.1M
pcpu_ida nolock 2.3M
bt 2.4M
kmalloc 1.8M
hlist+spinlock 2.3M
pcpu_freelist 2.6M
4 cpu:
pcpu_ida 1.5M
pcpu_ida nolock 1.8M
bt w/smp_align 1.7M
bt no/smp_align 1.1M
kmalloc 0.7M
hlist+spinlock 0.2M
pcpu_freelist 2.0M
8 cpu:
pcpu_ida 0.7M
bt w/smp_align 0.8M
kmalloc 0.4M
pcpu_freelist 1.5M
32 cpu:
kmalloc 0.13M
pcpu_freelist 0.49M
pcpu_ida nolock is a modified percpu_ida algorithm without
percpu_ida_cpu locks and without cross-cpu tag stealing.
It's faster than existing percpu_ida, but not as fast as pcpu_freelist.
bt is a variant of block/blk-mq-tag.c simlified and customized
for bpf use case. bt w/smp_align is using cache line for every 'long'
(similar to blk-mq-tag). bt no/smp_align allocates 'long'
bitmasks continuously to save memory. It's comparable to percpu_ida
and in some cases faster, but slower than percpu_freelist
hlist+spinlock is the simplest free list with single spinlock.
As expeceted it has very bad scaling in SMP.
kmalloc is existing implementation which is still available via
BPF_F_NO_PREALLOC flag. It's significantly slower in single cpu and
in 8 cpu setup it's 3 times slower than pre-allocation with pcpu_freelist,
but saves memory, so in cases where map->max_entries can be large
and number of map update/delete per second is low, it may make
sense to use it.
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2016-03-08 13:57:15 +08:00
|
|
|
if (err)
|
|
|
|
goto free_elems;
|
|
|
|
|
2016-11-12 02:55:09 +08:00
|
|
|
if (htab_is_lru(htab))
|
|
|
|
bpf_lru_populate(&htab->lru, htab->elems,
|
|
|
|
offsetof(struct htab_elem, lru_node),
|
2017-03-22 10:05:04 +08:00
|
|
|
htab->elem_size, num_entries);
|
2016-11-12 02:55:09 +08:00
|
|
|
else
|
2017-03-08 12:00:12 +08:00
|
|
|
pcpu_freelist_populate(&htab->freelist,
|
|
|
|
htab->elems + offsetof(struct htab_elem, fnode),
|
2017-03-22 10:05:04 +08:00
|
|
|
htab->elem_size, num_entries);
|
2016-11-12 02:55:09 +08:00
|
|
|
|
bpf: pre-allocate hash map elements
If kprobe is placed on spin_unlock then calling kmalloc/kfree from
bpf programs is not safe, since the following dead lock is possible:
kfree->spin_lock(kmem_cache_node->lock)...spin_unlock->kprobe->
bpf_prog->map_update->kmalloc->spin_lock(of the same kmem_cache_node->lock)
and deadlocks.
The following solutions were considered and some implemented, but
eventually discarded
- kmem_cache_create for every map
- add recursion check to slow-path of slub
- use reserved memory in bpf_map_update for in_irq or in preempt_disabled
- kmalloc via irq_work
At the end pre-allocation of all map elements turned out to be the simplest
solution and since the user is charged upfront for all the memory, such
pre-allocation doesn't affect the user space visible behavior.
Since it's impossible to tell whether kprobe is triggered in a safe
location from kmalloc point of view, use pre-allocation by default
and introduce new BPF_F_NO_PREALLOC flag.
While testing of per-cpu hash maps it was discovered
that alloc_percpu(GFP_ATOMIC) has odd corner cases and often
fails to allocate memory even when 90% of it is free.
The pre-allocation of per-cpu hash elements solves this problem as well.
Turned out that bpf_map_update() quickly followed by
bpf_map_lookup()+bpf_map_delete() is very common pattern used
in many of iovisor/bcc/tools, so there is additional benefit of
pre-allocation, since such use cases are must faster.
Since all hash map elements are now pre-allocated we can remove
atomic increment of htab->count and save few more cycles.
Also add bpf_map_precharge_memlock() to check rlimit_memlock early to avoid
large malloc/free done by users who don't have sufficient limits.
Pre-allocation is done with vmalloc and alloc/free is done
via percpu_freelist. Here are performance numbers for different
pre-allocation algorithms that were implemented, but discarded
in favor of percpu_freelist:
1 cpu:
pcpu_ida 2.1M
pcpu_ida nolock 2.3M
bt 2.4M
kmalloc 1.8M
hlist+spinlock 2.3M
pcpu_freelist 2.6M
4 cpu:
pcpu_ida 1.5M
pcpu_ida nolock 1.8M
bt w/smp_align 1.7M
bt no/smp_align 1.1M
kmalloc 0.7M
hlist+spinlock 0.2M
pcpu_freelist 2.0M
8 cpu:
pcpu_ida 0.7M
bt w/smp_align 0.8M
kmalloc 0.4M
pcpu_freelist 1.5M
32 cpu:
kmalloc 0.13M
pcpu_freelist 0.49M
pcpu_ida nolock is a modified percpu_ida algorithm without
percpu_ida_cpu locks and without cross-cpu tag stealing.
It's faster than existing percpu_ida, but not as fast as pcpu_freelist.
bt is a variant of block/blk-mq-tag.c simlified and customized
for bpf use case. bt w/smp_align is using cache line for every 'long'
(similar to blk-mq-tag). bt no/smp_align allocates 'long'
bitmasks continuously to save memory. It's comparable to percpu_ida
and in some cases faster, but slower than percpu_freelist
hlist+spinlock is the simplest free list with single spinlock.
As expeceted it has very bad scaling in SMP.
kmalloc is existing implementation which is still available via
BPF_F_NO_PREALLOC flag. It's significantly slower in single cpu and
in 8 cpu setup it's 3 times slower than pre-allocation with pcpu_freelist,
but saves memory, so in cases where map->max_entries can be large
and number of map update/delete per second is low, it may make
sense to use it.
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2016-03-08 13:57:15 +08:00
|
|
|
return 0;
|
|
|
|
|
|
|
|
free_elems:
|
|
|
|
htab_free_elems(htab);
|
|
|
|
return err;
|
|
|
|
}
|
|
|
|
|
2016-11-12 02:55:09 +08:00
|
|
|
static void prealloc_destroy(struct bpf_htab *htab)
|
|
|
|
{
|
|
|
|
htab_free_elems(htab);
|
|
|
|
|
|
|
|
if (htab_is_lru(htab))
|
|
|
|
bpf_lru_destroy(&htab->lru);
|
|
|
|
else
|
|
|
|
pcpu_freelist_destroy(&htab->freelist);
|
|
|
|
}
|
|
|
|
|
2016-08-06 05:01:27 +08:00
|
|
|
static int alloc_extra_elems(struct bpf_htab *htab)
|
|
|
|
{
|
2017-03-22 10:05:04 +08:00
|
|
|
struct htab_elem *__percpu *pptr, *l_new;
|
|
|
|
struct pcpu_freelist_node *l;
|
2016-08-06 05:01:27 +08:00
|
|
|
int cpu;
|
|
|
|
|
2017-03-22 10:05:04 +08:00
|
|
|
pptr = __alloc_percpu_gfp(sizeof(struct htab_elem *), 8,
|
|
|
|
GFP_USER | __GFP_NOWARN);
|
2016-08-06 05:01:27 +08:00
|
|
|
if (!pptr)
|
|
|
|
return -ENOMEM;
|
|
|
|
|
|
|
|
for_each_possible_cpu(cpu) {
|
2017-03-22 10:05:04 +08:00
|
|
|
l = pcpu_freelist_pop(&htab->freelist);
|
|
|
|
/* pop will succeed, since prealloc_init()
|
|
|
|
* preallocated extra num_possible_cpus elements
|
|
|
|
*/
|
|
|
|
l_new = container_of(l, struct htab_elem, fnode);
|
|
|
|
*per_cpu_ptr(pptr, cpu) = l_new;
|
2016-08-06 05:01:27 +08:00
|
|
|
}
|
|
|
|
htab->extra_elems = pptr;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2014-11-14 09:36:45 +08:00
|
|
|
/* Called from syscall */
|
2018-01-12 12:29:05 +08:00
|
|
|
static int htab_map_alloc_check(union bpf_attr *attr)
|
2014-11-14 09:36:45 +08:00
|
|
|
{
|
2016-11-12 02:55:10 +08:00
|
|
|
bool percpu = (attr->map_type == BPF_MAP_TYPE_PERCPU_HASH ||
|
|
|
|
attr->map_type == BPF_MAP_TYPE_LRU_PERCPU_HASH);
|
|
|
|
bool lru = (attr->map_type == BPF_MAP_TYPE_LRU_HASH ||
|
|
|
|
attr->map_type == BPF_MAP_TYPE_LRU_PERCPU_HASH);
|
2016-11-12 02:55:09 +08:00
|
|
|
/* percpu_lru means each cpu has its own LRU list.
|
|
|
|
* it is different from BPF_MAP_TYPE_PERCPU_HASH where
|
|
|
|
* the map's value itself is percpu. percpu_lru has
|
|
|
|
* nothing to do with the map's value.
|
|
|
|
*/
|
|
|
|
bool percpu_lru = (attr->map_flags & BPF_F_NO_COMMON_LRU);
|
|
|
|
bool prealloc = !(attr->map_flags & BPF_F_NO_PREALLOC);
|
2018-11-16 19:41:08 +08:00
|
|
|
bool zero_seed = (attr->map_flags & BPF_F_ZERO_SEED);
|
2017-08-19 02:28:00 +08:00
|
|
|
int numa_node = bpf_map_attr_numa_node(attr);
|
2014-11-14 09:36:45 +08:00
|
|
|
|
2017-03-08 12:00:12 +08:00
|
|
|
BUILD_BUG_ON(offsetof(struct htab_elem, htab) !=
|
|
|
|
offsetof(struct htab_elem, hash_node.pprev));
|
|
|
|
BUILD_BUG_ON(offsetof(struct htab_elem, fnode.next) !=
|
|
|
|
offsetof(struct htab_elem, hash_node.pprev));
|
|
|
|
|
2016-11-12 02:55:09 +08:00
|
|
|
if (lru && !capable(CAP_SYS_ADMIN))
|
|
|
|
/* LRU implementation is much complicated than other
|
|
|
|
* maps. Hence, limit to CAP_SYS_ADMIN for now.
|
|
|
|
*/
|
2018-01-12 12:29:05 +08:00
|
|
|
return -EPERM;
|
2016-11-12 02:55:09 +08:00
|
|
|
|
2018-11-16 19:41:08 +08:00
|
|
|
if (zero_seed && !capable(CAP_SYS_ADMIN))
|
|
|
|
/* Guard against local DoS, and discourage production use. */
|
|
|
|
return -EPERM;
|
|
|
|
|
bpf: add program side {rd, wr}only support for maps
This work adds two new map creation flags BPF_F_RDONLY_PROG
and BPF_F_WRONLY_PROG in order to allow for read-only or
write-only BPF maps from a BPF program side.
Today we have BPF_F_RDONLY and BPF_F_WRONLY, but this only
applies to system call side, meaning the BPF program has full
read/write access to the map as usual while bpf(2) calls with
map fd can either only read or write into the map depending
on the flags. BPF_F_RDONLY_PROG and BPF_F_WRONLY_PROG allows
for the exact opposite such that verifier is going to reject
program loads if write into a read-only map or a read into a
write-only map is detected. For read-only map case also some
helpers are forbidden for programs that would alter the map
state such as map deletion, update, etc. As opposed to the two
BPF_F_RDONLY / BPF_F_WRONLY flags, BPF_F_RDONLY_PROG as well
as BPF_F_WRONLY_PROG really do correspond to the map lifetime.
We've enabled this generic map extension to various non-special
maps holding normal user data: array, hash, lru, lpm, local
storage, queue and stack. Further generic map types could be
followed up in future depending on use-case. Main use case
here is to forbid writes into .rodata map values from verifier
side.
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Martin KaFai Lau <kafai@fb.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2019-04-10 05:20:05 +08:00
|
|
|
if (attr->map_flags & ~HTAB_CREATE_FLAG_MASK ||
|
|
|
|
!bpf_map_flags_access_ok(attr->map_flags))
|
2018-01-12 12:29:05 +08:00
|
|
|
return -EINVAL;
|
bpf: pre-allocate hash map elements
If kprobe is placed on spin_unlock then calling kmalloc/kfree from
bpf programs is not safe, since the following dead lock is possible:
kfree->spin_lock(kmem_cache_node->lock)...spin_unlock->kprobe->
bpf_prog->map_update->kmalloc->spin_lock(of the same kmem_cache_node->lock)
and deadlocks.
The following solutions were considered and some implemented, but
eventually discarded
- kmem_cache_create for every map
- add recursion check to slow-path of slub
- use reserved memory in bpf_map_update for in_irq or in preempt_disabled
- kmalloc via irq_work
At the end pre-allocation of all map elements turned out to be the simplest
solution and since the user is charged upfront for all the memory, such
pre-allocation doesn't affect the user space visible behavior.
Since it's impossible to tell whether kprobe is triggered in a safe
location from kmalloc point of view, use pre-allocation by default
and introduce new BPF_F_NO_PREALLOC flag.
While testing of per-cpu hash maps it was discovered
that alloc_percpu(GFP_ATOMIC) has odd corner cases and often
fails to allocate memory even when 90% of it is free.
The pre-allocation of per-cpu hash elements solves this problem as well.
Turned out that bpf_map_update() quickly followed by
bpf_map_lookup()+bpf_map_delete() is very common pattern used
in many of iovisor/bcc/tools, so there is additional benefit of
pre-allocation, since such use cases are must faster.
Since all hash map elements are now pre-allocated we can remove
atomic increment of htab->count and save few more cycles.
Also add bpf_map_precharge_memlock() to check rlimit_memlock early to avoid
large malloc/free done by users who don't have sufficient limits.
Pre-allocation is done with vmalloc and alloc/free is done
via percpu_freelist. Here are performance numbers for different
pre-allocation algorithms that were implemented, but discarded
in favor of percpu_freelist:
1 cpu:
pcpu_ida 2.1M
pcpu_ida nolock 2.3M
bt 2.4M
kmalloc 1.8M
hlist+spinlock 2.3M
pcpu_freelist 2.6M
4 cpu:
pcpu_ida 1.5M
pcpu_ida nolock 1.8M
bt w/smp_align 1.7M
bt no/smp_align 1.1M
kmalloc 0.7M
hlist+spinlock 0.2M
pcpu_freelist 2.0M
8 cpu:
pcpu_ida 0.7M
bt w/smp_align 0.8M
kmalloc 0.4M
pcpu_freelist 1.5M
32 cpu:
kmalloc 0.13M
pcpu_freelist 0.49M
pcpu_ida nolock is a modified percpu_ida algorithm without
percpu_ida_cpu locks and without cross-cpu tag stealing.
It's faster than existing percpu_ida, but not as fast as pcpu_freelist.
bt is a variant of block/blk-mq-tag.c simlified and customized
for bpf use case. bt w/smp_align is using cache line for every 'long'
(similar to blk-mq-tag). bt no/smp_align allocates 'long'
bitmasks continuously to save memory. It's comparable to percpu_ida
and in some cases faster, but slower than percpu_freelist
hlist+spinlock is the simplest free list with single spinlock.
As expeceted it has very bad scaling in SMP.
kmalloc is existing implementation which is still available via
BPF_F_NO_PREALLOC flag. It's significantly slower in single cpu and
in 8 cpu setup it's 3 times slower than pre-allocation with pcpu_freelist,
but saves memory, so in cases where map->max_entries can be large
and number of map update/delete per second is low, it may make
sense to use it.
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2016-03-08 13:57:15 +08:00
|
|
|
|
2016-11-12 02:55:09 +08:00
|
|
|
if (!lru && percpu_lru)
|
2018-01-12 12:29:05 +08:00
|
|
|
return -EINVAL;
|
2016-11-12 02:55:09 +08:00
|
|
|
|
|
|
|
if (lru && !prealloc)
|
2018-01-12 12:29:05 +08:00
|
|
|
return -ENOTSUPP;
|
2016-11-12 02:55:09 +08:00
|
|
|
|
2017-08-19 02:28:00 +08:00
|
|
|
if (numa_node != NUMA_NO_NODE && (percpu || percpu_lru))
|
2018-01-12 12:29:05 +08:00
|
|
|
return -EINVAL;
|
2017-08-19 02:28:00 +08:00
|
|
|
|
2018-01-12 12:29:04 +08:00
|
|
|
/* check sanity of attributes.
|
|
|
|
* value_size == 0 may be allowed in the future to use map as a set
|
|
|
|
*/
|
|
|
|
if (attr->max_entries == 0 || attr->key_size == 0 ||
|
|
|
|
attr->value_size == 0)
|
2018-01-12 12:29:05 +08:00
|
|
|
return -EINVAL;
|
2018-01-12 12:29:04 +08:00
|
|
|
|
|
|
|
if (attr->key_size > MAX_BPF_STACK)
|
|
|
|
/* eBPF programs initialize keys on stack, so they cannot be
|
|
|
|
* larger than max stack size
|
|
|
|
*/
|
2018-01-12 12:29:05 +08:00
|
|
|
return -E2BIG;
|
2018-01-12 12:29:04 +08:00
|
|
|
|
|
|
|
if (attr->value_size >= KMALLOC_MAX_SIZE -
|
|
|
|
MAX_BPF_STACK - sizeof(struct htab_elem))
|
|
|
|
/* if value_size is bigger, the user space won't be able to
|
|
|
|
* access the elements via bpf syscall. This check also makes
|
|
|
|
* sure that the elem_size doesn't overflow and it's
|
|
|
|
* kmalloc-able later in htab_map_update_elem()
|
|
|
|
*/
|
2018-01-12 12:29:05 +08:00
|
|
|
return -E2BIG;
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static struct bpf_map *htab_map_alloc(union bpf_attr *attr)
|
|
|
|
{
|
|
|
|
bool percpu = (attr->map_type == BPF_MAP_TYPE_PERCPU_HASH ||
|
|
|
|
attr->map_type == BPF_MAP_TYPE_LRU_PERCPU_HASH);
|
|
|
|
bool lru = (attr->map_type == BPF_MAP_TYPE_LRU_HASH ||
|
|
|
|
attr->map_type == BPF_MAP_TYPE_LRU_PERCPU_HASH);
|
|
|
|
/* percpu_lru means each cpu has its own LRU list.
|
|
|
|
* it is different from BPF_MAP_TYPE_PERCPU_HASH where
|
|
|
|
* the map's value itself is percpu. percpu_lru has
|
|
|
|
* nothing to do with the map's value.
|
|
|
|
*/
|
|
|
|
bool percpu_lru = (attr->map_flags & BPF_F_NO_COMMON_LRU);
|
|
|
|
bool prealloc = !(attr->map_flags & BPF_F_NO_PREALLOC);
|
|
|
|
struct bpf_htab *htab;
|
|
|
|
u64 cost;
|
2020-02-24 22:01:50 +08:00
|
|
|
int err;
|
2018-01-12 12:29:04 +08:00
|
|
|
|
2014-11-14 09:36:45 +08:00
|
|
|
htab = kzalloc(sizeof(*htab), GFP_USER);
|
|
|
|
if (!htab)
|
|
|
|
return ERR_PTR(-ENOMEM);
|
|
|
|
|
2018-01-12 12:29:06 +08:00
|
|
|
bpf_map_init_from_attr(&htab->map, attr);
|
2014-11-14 09:36:45 +08:00
|
|
|
|
2016-11-12 02:55:09 +08:00
|
|
|
if (percpu_lru) {
|
|
|
|
/* ensure each CPU's lru list has >=1 elements.
|
|
|
|
* since we are at it, make each lru list has the same
|
|
|
|
* number of elements.
|
|
|
|
*/
|
|
|
|
htab->map.max_entries = roundup(attr->max_entries,
|
|
|
|
num_possible_cpus());
|
|
|
|
if (htab->map.max_entries < attr->max_entries)
|
|
|
|
htab->map.max_entries = rounddown(attr->max_entries,
|
|
|
|
num_possible_cpus());
|
|
|
|
}
|
|
|
|
|
2014-11-14 09:36:45 +08:00
|
|
|
/* hash table size must be power of 2 */
|
|
|
|
htab->n_buckets = roundup_pow_of_two(htab->map.max_entries);
|
|
|
|
|
2015-11-30 08:59:35 +08:00
|
|
|
htab->elem_size = sizeof(struct htab_elem) +
|
2016-02-02 14:39:53 +08:00
|
|
|
round_up(htab->map.key_size, 8);
|
|
|
|
if (percpu)
|
|
|
|
htab->elem_size += sizeof(void *);
|
|
|
|
else
|
bpf: pre-allocate hash map elements
If kprobe is placed on spin_unlock then calling kmalloc/kfree from
bpf programs is not safe, since the following dead lock is possible:
kfree->spin_lock(kmem_cache_node->lock)...spin_unlock->kprobe->
bpf_prog->map_update->kmalloc->spin_lock(of the same kmem_cache_node->lock)
and deadlocks.
The following solutions were considered and some implemented, but
eventually discarded
- kmem_cache_create for every map
- add recursion check to slow-path of slub
- use reserved memory in bpf_map_update for in_irq or in preempt_disabled
- kmalloc via irq_work
At the end pre-allocation of all map elements turned out to be the simplest
solution and since the user is charged upfront for all the memory, such
pre-allocation doesn't affect the user space visible behavior.
Since it's impossible to tell whether kprobe is triggered in a safe
location from kmalloc point of view, use pre-allocation by default
and introduce new BPF_F_NO_PREALLOC flag.
While testing of per-cpu hash maps it was discovered
that alloc_percpu(GFP_ATOMIC) has odd corner cases and often
fails to allocate memory even when 90% of it is free.
The pre-allocation of per-cpu hash elements solves this problem as well.
Turned out that bpf_map_update() quickly followed by
bpf_map_lookup()+bpf_map_delete() is very common pattern used
in many of iovisor/bcc/tools, so there is additional benefit of
pre-allocation, since such use cases are must faster.
Since all hash map elements are now pre-allocated we can remove
atomic increment of htab->count and save few more cycles.
Also add bpf_map_precharge_memlock() to check rlimit_memlock early to avoid
large malloc/free done by users who don't have sufficient limits.
Pre-allocation is done with vmalloc and alloc/free is done
via percpu_freelist. Here are performance numbers for different
pre-allocation algorithms that were implemented, but discarded
in favor of percpu_freelist:
1 cpu:
pcpu_ida 2.1M
pcpu_ida nolock 2.3M
bt 2.4M
kmalloc 1.8M
hlist+spinlock 2.3M
pcpu_freelist 2.6M
4 cpu:
pcpu_ida 1.5M
pcpu_ida nolock 1.8M
bt w/smp_align 1.7M
bt no/smp_align 1.1M
kmalloc 0.7M
hlist+spinlock 0.2M
pcpu_freelist 2.0M
8 cpu:
pcpu_ida 0.7M
bt w/smp_align 0.8M
kmalloc 0.4M
pcpu_freelist 1.5M
32 cpu:
kmalloc 0.13M
pcpu_freelist 0.49M
pcpu_ida nolock is a modified percpu_ida algorithm without
percpu_ida_cpu locks and without cross-cpu tag stealing.
It's faster than existing percpu_ida, but not as fast as pcpu_freelist.
bt is a variant of block/blk-mq-tag.c simlified and customized
for bpf use case. bt w/smp_align is using cache line for every 'long'
(similar to blk-mq-tag). bt no/smp_align allocates 'long'
bitmasks continuously to save memory. It's comparable to percpu_ida
and in some cases faster, but slower than percpu_freelist
hlist+spinlock is the simplest free list with single spinlock.
As expeceted it has very bad scaling in SMP.
kmalloc is existing implementation which is still available via
BPF_F_NO_PREALLOC flag. It's significantly slower in single cpu and
in 8 cpu setup it's 3 times slower than pre-allocation with pcpu_freelist,
but saves memory, so in cases where map->max_entries can be large
and number of map update/delete per second is low, it may make
sense to use it.
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2016-03-08 13:57:15 +08:00
|
|
|
htab->elem_size += round_up(htab->map.value_size, 8);
|
2015-11-30 08:59:35 +08:00
|
|
|
|
2018-01-12 12:29:04 +08:00
|
|
|
err = -E2BIG;
|
2014-11-19 09:32:16 +08:00
|
|
|
/* prevent zero size kmalloc and check for u32 overflow */
|
|
|
|
if (htab->n_buckets == 0 ||
|
2015-12-29 22:40:27 +08:00
|
|
|
htab->n_buckets > U32_MAX / sizeof(struct bucket))
|
2014-11-19 09:32:16 +08:00
|
|
|
goto free_htab;
|
|
|
|
|
2016-02-02 14:39:53 +08:00
|
|
|
cost = (u64) htab->n_buckets * sizeof(struct bucket) +
|
|
|
|
(u64) htab->elem_size * htab->map.max_entries;
|
|
|
|
|
|
|
|
if (percpu)
|
|
|
|
cost += (u64) round_up(htab->map.value_size, 8) *
|
|
|
|
num_possible_cpus() * htab->map.max_entries;
|
2016-08-06 05:01:27 +08:00
|
|
|
else
|
|
|
|
cost += (u64) htab->elem_size * num_possible_cpus();
|
2016-02-02 14:39:53 +08:00
|
|
|
|
2019-05-30 09:03:58 +08:00
|
|
|
/* if map size is larger than memlock limit, reject it */
|
2019-05-30 09:03:59 +08:00
|
|
|
err = bpf_map_charge_init(&htab->map.memory, cost);
|
bpf: pre-allocate hash map elements
If kprobe is placed on spin_unlock then calling kmalloc/kfree from
bpf programs is not safe, since the following dead lock is possible:
kfree->spin_lock(kmem_cache_node->lock)...spin_unlock->kprobe->
bpf_prog->map_update->kmalloc->spin_lock(of the same kmem_cache_node->lock)
and deadlocks.
The following solutions were considered and some implemented, but
eventually discarded
- kmem_cache_create for every map
- add recursion check to slow-path of slub
- use reserved memory in bpf_map_update for in_irq or in preempt_disabled
- kmalloc via irq_work
At the end pre-allocation of all map elements turned out to be the simplest
solution and since the user is charged upfront for all the memory, such
pre-allocation doesn't affect the user space visible behavior.
Since it's impossible to tell whether kprobe is triggered in a safe
location from kmalloc point of view, use pre-allocation by default
and introduce new BPF_F_NO_PREALLOC flag.
While testing of per-cpu hash maps it was discovered
that alloc_percpu(GFP_ATOMIC) has odd corner cases and often
fails to allocate memory even when 90% of it is free.
The pre-allocation of per-cpu hash elements solves this problem as well.
Turned out that bpf_map_update() quickly followed by
bpf_map_lookup()+bpf_map_delete() is very common pattern used
in many of iovisor/bcc/tools, so there is additional benefit of
pre-allocation, since such use cases are must faster.
Since all hash map elements are now pre-allocated we can remove
atomic increment of htab->count and save few more cycles.
Also add bpf_map_precharge_memlock() to check rlimit_memlock early to avoid
large malloc/free done by users who don't have sufficient limits.
Pre-allocation is done with vmalloc and alloc/free is done
via percpu_freelist. Here are performance numbers for different
pre-allocation algorithms that were implemented, but discarded
in favor of percpu_freelist:
1 cpu:
pcpu_ida 2.1M
pcpu_ida nolock 2.3M
bt 2.4M
kmalloc 1.8M
hlist+spinlock 2.3M
pcpu_freelist 2.6M
4 cpu:
pcpu_ida 1.5M
pcpu_ida nolock 1.8M
bt w/smp_align 1.7M
bt no/smp_align 1.1M
kmalloc 0.7M
hlist+spinlock 0.2M
pcpu_freelist 2.0M
8 cpu:
pcpu_ida 0.7M
bt w/smp_align 0.8M
kmalloc 0.4M
pcpu_freelist 1.5M
32 cpu:
kmalloc 0.13M
pcpu_freelist 0.49M
pcpu_ida nolock is a modified percpu_ida algorithm without
percpu_ida_cpu locks and without cross-cpu tag stealing.
It's faster than existing percpu_ida, but not as fast as pcpu_freelist.
bt is a variant of block/blk-mq-tag.c simlified and customized
for bpf use case. bt w/smp_align is using cache line for every 'long'
(similar to blk-mq-tag). bt no/smp_align allocates 'long'
bitmasks continuously to save memory. It's comparable to percpu_ida
and in some cases faster, but slower than percpu_freelist
hlist+spinlock is the simplest free list with single spinlock.
As expeceted it has very bad scaling in SMP.
kmalloc is existing implementation which is still available via
BPF_F_NO_PREALLOC flag. It's significantly slower in single cpu and
in 8 cpu setup it's 3 times slower than pre-allocation with pcpu_freelist,
but saves memory, so in cases where map->max_entries can be large
and number of map update/delete per second is low, it may make
sense to use it.
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2016-03-08 13:57:15 +08:00
|
|
|
if (err)
|
|
|
|
goto free_htab;
|
|
|
|
|
2015-11-30 08:59:35 +08:00
|
|
|
err = -ENOMEM;
|
bpf: don't trigger OOM killer under pressure with map alloc
This patch adds two helpers, bpf_map_area_alloc() and bpf_map_area_free(),
that are to be used for map allocations. Using kmalloc() for very large
allocations can cause excessive work within the page allocator, so i) fall
back earlier to vmalloc() when the attempt is considered costly anyway,
and even more importantly ii) don't trigger OOM killer with any of the
allocators.
Since this is based on a user space request, for example, when creating
maps with element pre-allocation, we really want such requests to fail
instead of killing other user space processes.
Also, don't spam the kernel log with warnings should any of the allocations
fail under pressure. Given that, we can make backend selection in
bpf_map_area_alloc() generic, and convert all maps over to use this API
for spots with potentially large allocation requests.
Note, replacing the one kmalloc_array() is fine as overflow checks happen
earlier in htab_map_alloc(), since it must also protect the multiplication
for vmalloc() should kmalloc_array() fail.
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-01-18 22:14:17 +08:00
|
|
|
htab->buckets = bpf_map_area_alloc(htab->n_buckets *
|
2017-08-19 02:28:00 +08:00
|
|
|
sizeof(struct bucket),
|
|
|
|
htab->map.numa_node);
|
bpf: don't trigger OOM killer under pressure with map alloc
This patch adds two helpers, bpf_map_area_alloc() and bpf_map_area_free(),
that are to be used for map allocations. Using kmalloc() for very large
allocations can cause excessive work within the page allocator, so i) fall
back earlier to vmalloc() when the attempt is considered costly anyway,
and even more importantly ii) don't trigger OOM killer with any of the
allocators.
Since this is based on a user space request, for example, when creating
maps with element pre-allocation, we really want such requests to fail
instead of killing other user space processes.
Also, don't spam the kernel log with warnings should any of the allocations
fail under pressure. Given that, we can make backend selection in
bpf_map_area_alloc() generic, and convert all maps over to use this API
for spots with potentially large allocation requests.
Note, replacing the one kmalloc_array() is fine as overflow checks happen
earlier in htab_map_alloc(), since it must also protect the multiplication
for vmalloc() should kmalloc_array() fail.
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-01-18 22:14:17 +08:00
|
|
|
if (!htab->buckets)
|
2019-05-30 09:03:58 +08:00
|
|
|
goto free_charge;
|
2014-11-14 09:36:45 +08:00
|
|
|
|
2018-11-16 19:41:08 +08:00
|
|
|
if (htab->map.map_flags & BPF_F_ZERO_SEED)
|
|
|
|
htab->hashrnd = 0;
|
|
|
|
else
|
|
|
|
htab->hashrnd = get_random_int();
|
|
|
|
|
2020-02-24 22:01:50 +08:00
|
|
|
htab_init_buckets(htab);
|
2014-11-14 09:36:45 +08:00
|
|
|
|
2016-11-12 02:55:09 +08:00
|
|
|
if (prealloc) {
|
|
|
|
err = prealloc_init(htab);
|
bpf: pre-allocate hash map elements
If kprobe is placed on spin_unlock then calling kmalloc/kfree from
bpf programs is not safe, since the following dead lock is possible:
kfree->spin_lock(kmem_cache_node->lock)...spin_unlock->kprobe->
bpf_prog->map_update->kmalloc->spin_lock(of the same kmem_cache_node->lock)
and deadlocks.
The following solutions were considered and some implemented, but
eventually discarded
- kmem_cache_create for every map
- add recursion check to slow-path of slub
- use reserved memory in bpf_map_update for in_irq or in preempt_disabled
- kmalloc via irq_work
At the end pre-allocation of all map elements turned out to be the simplest
solution and since the user is charged upfront for all the memory, such
pre-allocation doesn't affect the user space visible behavior.
Since it's impossible to tell whether kprobe is triggered in a safe
location from kmalloc point of view, use pre-allocation by default
and introduce new BPF_F_NO_PREALLOC flag.
While testing of per-cpu hash maps it was discovered
that alloc_percpu(GFP_ATOMIC) has odd corner cases and often
fails to allocate memory even when 90% of it is free.
The pre-allocation of per-cpu hash elements solves this problem as well.
Turned out that bpf_map_update() quickly followed by
bpf_map_lookup()+bpf_map_delete() is very common pattern used
in many of iovisor/bcc/tools, so there is additional benefit of
pre-allocation, since such use cases are must faster.
Since all hash map elements are now pre-allocated we can remove
atomic increment of htab->count and save few more cycles.
Also add bpf_map_precharge_memlock() to check rlimit_memlock early to avoid
large malloc/free done by users who don't have sufficient limits.
Pre-allocation is done with vmalloc and alloc/free is done
via percpu_freelist. Here are performance numbers for different
pre-allocation algorithms that were implemented, but discarded
in favor of percpu_freelist:
1 cpu:
pcpu_ida 2.1M
pcpu_ida nolock 2.3M
bt 2.4M
kmalloc 1.8M
hlist+spinlock 2.3M
pcpu_freelist 2.6M
4 cpu:
pcpu_ida 1.5M
pcpu_ida nolock 1.8M
bt w/smp_align 1.7M
bt no/smp_align 1.1M
kmalloc 0.7M
hlist+spinlock 0.2M
pcpu_freelist 2.0M
8 cpu:
pcpu_ida 0.7M
bt w/smp_align 0.8M
kmalloc 0.4M
pcpu_freelist 1.5M
32 cpu:
kmalloc 0.13M
pcpu_freelist 0.49M
pcpu_ida nolock is a modified percpu_ida algorithm without
percpu_ida_cpu locks and without cross-cpu tag stealing.
It's faster than existing percpu_ida, but not as fast as pcpu_freelist.
bt is a variant of block/blk-mq-tag.c simlified and customized
for bpf use case. bt w/smp_align is using cache line for every 'long'
(similar to blk-mq-tag). bt no/smp_align allocates 'long'
bitmasks continuously to save memory. It's comparable to percpu_ida
and in some cases faster, but slower than percpu_freelist
hlist+spinlock is the simplest free list with single spinlock.
As expeceted it has very bad scaling in SMP.
kmalloc is existing implementation which is still available via
BPF_F_NO_PREALLOC flag. It's significantly slower in single cpu and
in 8 cpu setup it's 3 times slower than pre-allocation with pcpu_freelist,
but saves memory, so in cases where map->max_entries can be large
and number of map update/delete per second is low, it may make
sense to use it.
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2016-03-08 13:57:15 +08:00
|
|
|
if (err)
|
2017-03-22 10:05:04 +08:00
|
|
|
goto free_buckets;
|
|
|
|
|
|
|
|
if (!percpu && !lru) {
|
|
|
|
/* lru itself can remove the least used element, so
|
|
|
|
* there is no need for an extra elem during map_update.
|
|
|
|
*/
|
|
|
|
err = alloc_extra_elems(htab);
|
|
|
|
if (err)
|
|
|
|
goto free_prealloc;
|
|
|
|
}
|
bpf: pre-allocate hash map elements
If kprobe is placed on spin_unlock then calling kmalloc/kfree from
bpf programs is not safe, since the following dead lock is possible:
kfree->spin_lock(kmem_cache_node->lock)...spin_unlock->kprobe->
bpf_prog->map_update->kmalloc->spin_lock(of the same kmem_cache_node->lock)
and deadlocks.
The following solutions were considered and some implemented, but
eventually discarded
- kmem_cache_create for every map
- add recursion check to slow-path of slub
- use reserved memory in bpf_map_update for in_irq or in preempt_disabled
- kmalloc via irq_work
At the end pre-allocation of all map elements turned out to be the simplest
solution and since the user is charged upfront for all the memory, such
pre-allocation doesn't affect the user space visible behavior.
Since it's impossible to tell whether kprobe is triggered in a safe
location from kmalloc point of view, use pre-allocation by default
and introduce new BPF_F_NO_PREALLOC flag.
While testing of per-cpu hash maps it was discovered
that alloc_percpu(GFP_ATOMIC) has odd corner cases and often
fails to allocate memory even when 90% of it is free.
The pre-allocation of per-cpu hash elements solves this problem as well.
Turned out that bpf_map_update() quickly followed by
bpf_map_lookup()+bpf_map_delete() is very common pattern used
in many of iovisor/bcc/tools, so there is additional benefit of
pre-allocation, since such use cases are must faster.
Since all hash map elements are now pre-allocated we can remove
atomic increment of htab->count and save few more cycles.
Also add bpf_map_precharge_memlock() to check rlimit_memlock early to avoid
large malloc/free done by users who don't have sufficient limits.
Pre-allocation is done with vmalloc and alloc/free is done
via percpu_freelist. Here are performance numbers for different
pre-allocation algorithms that were implemented, but discarded
in favor of percpu_freelist:
1 cpu:
pcpu_ida 2.1M
pcpu_ida nolock 2.3M
bt 2.4M
kmalloc 1.8M
hlist+spinlock 2.3M
pcpu_freelist 2.6M
4 cpu:
pcpu_ida 1.5M
pcpu_ida nolock 1.8M
bt w/smp_align 1.7M
bt no/smp_align 1.1M
kmalloc 0.7M
hlist+spinlock 0.2M
pcpu_freelist 2.0M
8 cpu:
pcpu_ida 0.7M
bt w/smp_align 0.8M
kmalloc 0.4M
pcpu_freelist 1.5M
32 cpu:
kmalloc 0.13M
pcpu_freelist 0.49M
pcpu_ida nolock is a modified percpu_ida algorithm without
percpu_ida_cpu locks and without cross-cpu tag stealing.
It's faster than existing percpu_ida, but not as fast as pcpu_freelist.
bt is a variant of block/blk-mq-tag.c simlified and customized
for bpf use case. bt w/smp_align is using cache line for every 'long'
(similar to blk-mq-tag). bt no/smp_align allocates 'long'
bitmasks continuously to save memory. It's comparable to percpu_ida
and in some cases faster, but slower than percpu_freelist
hlist+spinlock is the simplest free list with single spinlock.
As expeceted it has very bad scaling in SMP.
kmalloc is existing implementation which is still available via
BPF_F_NO_PREALLOC flag. It's significantly slower in single cpu and
in 8 cpu setup it's 3 times slower than pre-allocation with pcpu_freelist,
but saves memory, so in cases where map->max_entries can be large
and number of map update/delete per second is low, it may make
sense to use it.
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2016-03-08 13:57:15 +08:00
|
|
|
}
|
2014-11-14 09:36:45 +08:00
|
|
|
|
|
|
|
return &htab->map;
|
|
|
|
|
2017-03-22 10:05:04 +08:00
|
|
|
free_prealloc:
|
|
|
|
prealloc_destroy(htab);
|
bpf: pre-allocate hash map elements
If kprobe is placed on spin_unlock then calling kmalloc/kfree from
bpf programs is not safe, since the following dead lock is possible:
kfree->spin_lock(kmem_cache_node->lock)...spin_unlock->kprobe->
bpf_prog->map_update->kmalloc->spin_lock(of the same kmem_cache_node->lock)
and deadlocks.
The following solutions were considered and some implemented, but
eventually discarded
- kmem_cache_create for every map
- add recursion check to slow-path of slub
- use reserved memory in bpf_map_update for in_irq or in preempt_disabled
- kmalloc via irq_work
At the end pre-allocation of all map elements turned out to be the simplest
solution and since the user is charged upfront for all the memory, such
pre-allocation doesn't affect the user space visible behavior.
Since it's impossible to tell whether kprobe is triggered in a safe
location from kmalloc point of view, use pre-allocation by default
and introduce new BPF_F_NO_PREALLOC flag.
While testing of per-cpu hash maps it was discovered
that alloc_percpu(GFP_ATOMIC) has odd corner cases and often
fails to allocate memory even when 90% of it is free.
The pre-allocation of per-cpu hash elements solves this problem as well.
Turned out that bpf_map_update() quickly followed by
bpf_map_lookup()+bpf_map_delete() is very common pattern used
in many of iovisor/bcc/tools, so there is additional benefit of
pre-allocation, since such use cases are must faster.
Since all hash map elements are now pre-allocated we can remove
atomic increment of htab->count and save few more cycles.
Also add bpf_map_precharge_memlock() to check rlimit_memlock early to avoid
large malloc/free done by users who don't have sufficient limits.
Pre-allocation is done with vmalloc and alloc/free is done
via percpu_freelist. Here are performance numbers for different
pre-allocation algorithms that were implemented, but discarded
in favor of percpu_freelist:
1 cpu:
pcpu_ida 2.1M
pcpu_ida nolock 2.3M
bt 2.4M
kmalloc 1.8M
hlist+spinlock 2.3M
pcpu_freelist 2.6M
4 cpu:
pcpu_ida 1.5M
pcpu_ida nolock 1.8M
bt w/smp_align 1.7M
bt no/smp_align 1.1M
kmalloc 0.7M
hlist+spinlock 0.2M
pcpu_freelist 2.0M
8 cpu:
pcpu_ida 0.7M
bt w/smp_align 0.8M
kmalloc 0.4M
pcpu_freelist 1.5M
32 cpu:
kmalloc 0.13M
pcpu_freelist 0.49M
pcpu_ida nolock is a modified percpu_ida algorithm without
percpu_ida_cpu locks and without cross-cpu tag stealing.
It's faster than existing percpu_ida, but not as fast as pcpu_freelist.
bt is a variant of block/blk-mq-tag.c simlified and customized
for bpf use case. bt w/smp_align is using cache line for every 'long'
(similar to blk-mq-tag). bt no/smp_align allocates 'long'
bitmasks continuously to save memory. It's comparable to percpu_ida
and in some cases faster, but slower than percpu_freelist
hlist+spinlock is the simplest free list with single spinlock.
As expeceted it has very bad scaling in SMP.
kmalloc is existing implementation which is still available via
BPF_F_NO_PREALLOC flag. It's significantly slower in single cpu and
in 8 cpu setup it's 3 times slower than pre-allocation with pcpu_freelist,
but saves memory, so in cases where map->max_entries can be large
and number of map update/delete per second is low, it may make
sense to use it.
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2016-03-08 13:57:15 +08:00
|
|
|
free_buckets:
|
bpf: don't trigger OOM killer under pressure with map alloc
This patch adds two helpers, bpf_map_area_alloc() and bpf_map_area_free(),
that are to be used for map allocations. Using kmalloc() for very large
allocations can cause excessive work within the page allocator, so i) fall
back earlier to vmalloc() when the attempt is considered costly anyway,
and even more importantly ii) don't trigger OOM killer with any of the
allocators.
Since this is based on a user space request, for example, when creating
maps with element pre-allocation, we really want such requests to fail
instead of killing other user space processes.
Also, don't spam the kernel log with warnings should any of the allocations
fail under pressure. Given that, we can make backend selection in
bpf_map_area_alloc() generic, and convert all maps over to use this API
for spots with potentially large allocation requests.
Note, replacing the one kmalloc_array() is fine as overflow checks happen
earlier in htab_map_alloc(), since it must also protect the multiplication
for vmalloc() should kmalloc_array() fail.
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-01-18 22:14:17 +08:00
|
|
|
bpf_map_area_free(htab->buckets);
|
2019-05-30 09:03:58 +08:00
|
|
|
free_charge:
|
|
|
|
bpf_map_charge_finish(&htab->map.memory);
|
2014-11-14 09:36:45 +08:00
|
|
|
free_htab:
|
|
|
|
kfree(htab);
|
|
|
|
return ERR_PTR(err);
|
|
|
|
}
|
|
|
|
|
2018-08-23 05:49:37 +08:00
|
|
|
static inline u32 htab_map_hash(const void *key, u32 key_len, u32 hashrnd)
|
2014-11-14 09:36:45 +08:00
|
|
|
{
|
2018-08-23 05:49:37 +08:00
|
|
|
return jhash(key, key_len, hashrnd);
|
2014-11-14 09:36:45 +08:00
|
|
|
}
|
|
|
|
|
2015-12-29 22:40:27 +08:00
|
|
|
static inline struct bucket *__select_bucket(struct bpf_htab *htab, u32 hash)
|
2014-11-14 09:36:45 +08:00
|
|
|
{
|
|
|
|
return &htab->buckets[hash & (htab->n_buckets - 1)];
|
|
|
|
}
|
|
|
|
|
2017-03-08 12:00:13 +08:00
|
|
|
static inline struct hlist_nulls_head *select_bucket(struct bpf_htab *htab, u32 hash)
|
2015-12-29 22:40:27 +08:00
|
|
|
{
|
|
|
|
return &__select_bucket(htab, hash)->head;
|
|
|
|
}
|
|
|
|
|
2017-03-08 12:00:13 +08:00
|
|
|
/* this lookup function can only be called with bucket lock taken */
|
|
|
|
static struct htab_elem *lookup_elem_raw(struct hlist_nulls_head *head, u32 hash,
|
2014-11-14 09:36:45 +08:00
|
|
|
void *key, u32 key_size)
|
|
|
|
{
|
2017-03-08 12:00:13 +08:00
|
|
|
struct hlist_nulls_node *n;
|
2014-11-14 09:36:45 +08:00
|
|
|
struct htab_elem *l;
|
|
|
|
|
2017-03-08 12:00:13 +08:00
|
|
|
hlist_nulls_for_each_entry_rcu(l, n, head, hash_node)
|
2014-11-14 09:36:45 +08:00
|
|
|
if (l->hash == hash && !memcmp(&l->key, key, key_size))
|
|
|
|
return l;
|
|
|
|
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
2017-03-08 12:00:13 +08:00
|
|
|
/* can be called without bucket lock. it will repeat the loop in
|
|
|
|
* the unlikely event when elements moved from one bucket into another
|
|
|
|
* while link list is being walked
|
|
|
|
*/
|
|
|
|
static struct htab_elem *lookup_nulls_elem_raw(struct hlist_nulls_head *head,
|
|
|
|
u32 hash, void *key,
|
|
|
|
u32 key_size, u32 n_buckets)
|
|
|
|
{
|
|
|
|
struct hlist_nulls_node *n;
|
|
|
|
struct htab_elem *l;
|
|
|
|
|
|
|
|
again:
|
|
|
|
hlist_nulls_for_each_entry_rcu(l, n, head, hash_node)
|
|
|
|
if (l->hash == hash && !memcmp(&l->key, key, key_size))
|
|
|
|
return l;
|
|
|
|
|
|
|
|
if (unlikely(get_nulls_value(n) != (hash & (n_buckets - 1))))
|
|
|
|
goto again;
|
|
|
|
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
2017-03-16 09:26:43 +08:00
|
|
|
/* Called from syscall or from eBPF program directly, so
|
|
|
|
* arguments have to match bpf_map_lookup_elem() exactly.
|
|
|
|
* The return value is adjusted by BPF instructions
|
|
|
|
* in htab_map_gen_lookup().
|
|
|
|
*/
|
2016-02-02 14:39:53 +08:00
|
|
|
static void *__htab_map_lookup_elem(struct bpf_map *map, void *key)
|
2014-11-14 09:36:45 +08:00
|
|
|
{
|
|
|
|
struct bpf_htab *htab = container_of(map, struct bpf_htab, map);
|
2017-03-08 12:00:13 +08:00
|
|
|
struct hlist_nulls_head *head;
|
2014-11-14 09:36:45 +08:00
|
|
|
struct htab_elem *l;
|
|
|
|
u32 hash, key_size;
|
|
|
|
|
|
|
|
/* Must be called with rcu_read_lock. */
|
|
|
|
WARN_ON_ONCE(!rcu_read_lock_held());
|
|
|
|
|
|
|
|
key_size = map->key_size;
|
|
|
|
|
2018-08-23 05:49:37 +08:00
|
|
|
hash = htab_map_hash(key, key_size, htab->hashrnd);
|
2014-11-14 09:36:45 +08:00
|
|
|
|
|
|
|
head = select_bucket(htab, hash);
|
|
|
|
|
2017-03-08 12:00:13 +08:00
|
|
|
l = lookup_nulls_elem_raw(head, hash, key, key_size, htab->n_buckets);
|
2014-11-14 09:36:45 +08:00
|
|
|
|
2016-02-02 14:39:53 +08:00
|
|
|
return l;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void *htab_map_lookup_elem(struct bpf_map *map, void *key)
|
|
|
|
{
|
|
|
|
struct htab_elem *l = __htab_map_lookup_elem(map, key);
|
|
|
|
|
2014-11-14 09:36:45 +08:00
|
|
|
if (l)
|
|
|
|
return l->key + round_up(map->key_size, 8);
|
|
|
|
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
2017-03-16 09:26:43 +08:00
|
|
|
/* inline bpf_map_lookup_elem() call.
|
|
|
|
* Instead of:
|
|
|
|
* bpf_prog
|
|
|
|
* bpf_map_lookup_elem
|
|
|
|
* map->ops->map_lookup_elem
|
|
|
|
* htab_map_lookup_elem
|
|
|
|
* __htab_map_lookup_elem
|
|
|
|
* do:
|
|
|
|
* bpf_prog
|
|
|
|
* __htab_map_lookup_elem
|
|
|
|
*/
|
|
|
|
static u32 htab_map_gen_lookup(struct bpf_map *map, struct bpf_insn *insn_buf)
|
|
|
|
{
|
|
|
|
struct bpf_insn *insn = insn_buf;
|
|
|
|
const int ret = BPF_REG_0;
|
|
|
|
|
2018-06-03 05:06:35 +08:00
|
|
|
BUILD_BUG_ON(!__same_type(&__htab_map_lookup_elem,
|
|
|
|
(void *(*)(struct bpf_map *map, void *key))NULL));
|
|
|
|
*insn++ = BPF_EMIT_CALL(BPF_CAST_CALL(__htab_map_lookup_elem));
|
2017-03-16 09:26:43 +08:00
|
|
|
*insn++ = BPF_JMP_IMM(BPF_JEQ, ret, 0, 1);
|
|
|
|
*insn++ = BPF_ALU64_IMM(BPF_ADD, ret,
|
|
|
|
offsetof(struct htab_elem, key) +
|
|
|
|
round_up(map->key_size, 8));
|
|
|
|
return insn - insn_buf;
|
|
|
|
}
|
|
|
|
|
2019-05-14 07:18:56 +08:00
|
|
|
static __always_inline void *__htab_lru_map_lookup_elem(struct bpf_map *map,
|
|
|
|
void *key, const bool mark)
|
2016-11-12 02:55:09 +08:00
|
|
|
{
|
|
|
|
struct htab_elem *l = __htab_map_lookup_elem(map, key);
|
|
|
|
|
|
|
|
if (l) {
|
2019-05-14 07:18:56 +08:00
|
|
|
if (mark)
|
|
|
|
bpf_lru_node_set_ref(&l->lru_node);
|
2016-11-12 02:55:09 +08:00
|
|
|
return l->key + round_up(map->key_size, 8);
|
|
|
|
}
|
|
|
|
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
2019-05-14 07:18:56 +08:00
|
|
|
static void *htab_lru_map_lookup_elem(struct bpf_map *map, void *key)
|
|
|
|
{
|
|
|
|
return __htab_lru_map_lookup_elem(map, key, true);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void *htab_lru_map_lookup_elem_sys(struct bpf_map *map, void *key)
|
|
|
|
{
|
|
|
|
return __htab_lru_map_lookup_elem(map, key, false);
|
|
|
|
}
|
|
|
|
|
2017-09-01 14:27:12 +08:00
|
|
|
static u32 htab_lru_map_gen_lookup(struct bpf_map *map,
|
|
|
|
struct bpf_insn *insn_buf)
|
|
|
|
{
|
|
|
|
struct bpf_insn *insn = insn_buf;
|
|
|
|
const int ret = BPF_REG_0;
|
2017-09-01 14:27:13 +08:00
|
|
|
const int ref_reg = BPF_REG_1;
|
2017-09-01 14:27:12 +08:00
|
|
|
|
2018-06-03 05:06:35 +08:00
|
|
|
BUILD_BUG_ON(!__same_type(&__htab_map_lookup_elem,
|
|
|
|
(void *(*)(struct bpf_map *map, void *key))NULL));
|
|
|
|
*insn++ = BPF_EMIT_CALL(BPF_CAST_CALL(__htab_map_lookup_elem));
|
2017-09-01 14:27:13 +08:00
|
|
|
*insn++ = BPF_JMP_IMM(BPF_JEQ, ret, 0, 4);
|
|
|
|
*insn++ = BPF_LDX_MEM(BPF_B, ref_reg, ret,
|
|
|
|
offsetof(struct htab_elem, lru_node) +
|
|
|
|
offsetof(struct bpf_lru_node, ref));
|
|
|
|
*insn++ = BPF_JMP_IMM(BPF_JNE, ref_reg, 0, 1);
|
2017-09-01 14:27:12 +08:00
|
|
|
*insn++ = BPF_ST_MEM(BPF_B, ret,
|
|
|
|
offsetof(struct htab_elem, lru_node) +
|
|
|
|
offsetof(struct bpf_lru_node, ref),
|
|
|
|
1);
|
|
|
|
*insn++ = BPF_ALU64_IMM(BPF_ADD, ret,
|
|
|
|
offsetof(struct htab_elem, key) +
|
|
|
|
round_up(map->key_size, 8));
|
|
|
|
return insn - insn_buf;
|
|
|
|
}
|
|
|
|
|
2016-11-12 02:55:09 +08:00
|
|
|
/* It is called from the bpf_lru_list when the LRU needs to delete
|
|
|
|
* older elements from the htab.
|
|
|
|
*/
|
|
|
|
static bool htab_lru_map_delete_node(void *arg, struct bpf_lru_node *node)
|
|
|
|
{
|
|
|
|
struct bpf_htab *htab = (struct bpf_htab *)arg;
|
2017-03-08 12:00:13 +08:00
|
|
|
struct htab_elem *l = NULL, *tgt_l;
|
|
|
|
struct hlist_nulls_head *head;
|
|
|
|
struct hlist_nulls_node *n;
|
2016-11-12 02:55:09 +08:00
|
|
|
unsigned long flags;
|
|
|
|
struct bucket *b;
|
|
|
|
|
|
|
|
tgt_l = container_of(node, struct htab_elem, lru_node);
|
|
|
|
b = __select_bucket(htab, tgt_l->hash);
|
|
|
|
head = &b->head;
|
|
|
|
|
2020-02-24 22:01:50 +08:00
|
|
|
flags = htab_lock_bucket(htab, b);
|
2016-11-12 02:55:09 +08:00
|
|
|
|
2017-03-08 12:00:13 +08:00
|
|
|
hlist_nulls_for_each_entry_rcu(l, n, head, hash_node)
|
2016-11-12 02:55:09 +08:00
|
|
|
if (l == tgt_l) {
|
2017-03-08 12:00:13 +08:00
|
|
|
hlist_nulls_del_rcu(&l->hash_node);
|
2016-11-12 02:55:09 +08:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
2020-02-24 22:01:50 +08:00
|
|
|
htab_unlock_bucket(htab, b, flags);
|
2016-11-12 02:55:09 +08:00
|
|
|
|
|
|
|
return l == tgt_l;
|
|
|
|
}
|
|
|
|
|
2014-11-14 09:36:45 +08:00
|
|
|
/* Called from syscall */
|
|
|
|
static int htab_map_get_next_key(struct bpf_map *map, void *key, void *next_key)
|
|
|
|
{
|
|
|
|
struct bpf_htab *htab = container_of(map, struct bpf_htab, map);
|
2017-03-08 12:00:13 +08:00
|
|
|
struct hlist_nulls_head *head;
|
2014-11-14 09:36:45 +08:00
|
|
|
struct htab_elem *l, *next_l;
|
|
|
|
u32 hash, key_size;
|
2017-04-25 10:00:37 +08:00
|
|
|
int i = 0;
|
2014-11-14 09:36:45 +08:00
|
|
|
|
|
|
|
WARN_ON_ONCE(!rcu_read_lock_held());
|
|
|
|
|
|
|
|
key_size = map->key_size;
|
|
|
|
|
2017-04-25 10:00:37 +08:00
|
|
|
if (!key)
|
|
|
|
goto find_first_elem;
|
|
|
|
|
2018-08-23 05:49:37 +08:00
|
|
|
hash = htab_map_hash(key, key_size, htab->hashrnd);
|
2014-11-14 09:36:45 +08:00
|
|
|
|
|
|
|
head = select_bucket(htab, hash);
|
|
|
|
|
|
|
|
/* lookup the key */
|
2017-03-08 12:00:13 +08:00
|
|
|
l = lookup_nulls_elem_raw(head, hash, key, key_size, htab->n_buckets);
|
2014-11-14 09:36:45 +08:00
|
|
|
|
2017-04-25 10:00:37 +08:00
|
|
|
if (!l)
|
2014-11-14 09:36:45 +08:00
|
|
|
goto find_first_elem;
|
|
|
|
|
|
|
|
/* key was found, get next key in the same bucket */
|
2017-03-08 12:00:13 +08:00
|
|
|
next_l = hlist_nulls_entry_safe(rcu_dereference_raw(hlist_nulls_next_rcu(&l->hash_node)),
|
2014-11-14 09:36:45 +08:00
|
|
|
struct htab_elem, hash_node);
|
|
|
|
|
|
|
|
if (next_l) {
|
|
|
|
/* if next elem in this hash list is non-zero, just return it */
|
|
|
|
memcpy(next_key, next_l->key, key_size);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* no more elements in this hash list, go to the next bucket */
|
|
|
|
i = hash & (htab->n_buckets - 1);
|
|
|
|
i++;
|
|
|
|
|
|
|
|
find_first_elem:
|
|
|
|
/* iterate over buckets */
|
|
|
|
for (; i < htab->n_buckets; i++) {
|
|
|
|
head = select_bucket(htab, i);
|
|
|
|
|
|
|
|
/* pick first element in the bucket */
|
2017-03-08 12:00:13 +08:00
|
|
|
next_l = hlist_nulls_entry_safe(rcu_dereference_raw(hlist_nulls_first_rcu(head)),
|
2014-11-14 09:36:45 +08:00
|
|
|
struct htab_elem, hash_node);
|
|
|
|
if (next_l) {
|
|
|
|
/* if it's not empty, just return it */
|
|
|
|
memcpy(next_key, next_l->key, key_size);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
bpf: pre-allocate hash map elements
If kprobe is placed on spin_unlock then calling kmalloc/kfree from
bpf programs is not safe, since the following dead lock is possible:
kfree->spin_lock(kmem_cache_node->lock)...spin_unlock->kprobe->
bpf_prog->map_update->kmalloc->spin_lock(of the same kmem_cache_node->lock)
and deadlocks.
The following solutions were considered and some implemented, but
eventually discarded
- kmem_cache_create for every map
- add recursion check to slow-path of slub
- use reserved memory in bpf_map_update for in_irq or in preempt_disabled
- kmalloc via irq_work
At the end pre-allocation of all map elements turned out to be the simplest
solution and since the user is charged upfront for all the memory, such
pre-allocation doesn't affect the user space visible behavior.
Since it's impossible to tell whether kprobe is triggered in a safe
location from kmalloc point of view, use pre-allocation by default
and introduce new BPF_F_NO_PREALLOC flag.
While testing of per-cpu hash maps it was discovered
that alloc_percpu(GFP_ATOMIC) has odd corner cases and often
fails to allocate memory even when 90% of it is free.
The pre-allocation of per-cpu hash elements solves this problem as well.
Turned out that bpf_map_update() quickly followed by
bpf_map_lookup()+bpf_map_delete() is very common pattern used
in many of iovisor/bcc/tools, so there is additional benefit of
pre-allocation, since such use cases are must faster.
Since all hash map elements are now pre-allocated we can remove
atomic increment of htab->count and save few more cycles.
Also add bpf_map_precharge_memlock() to check rlimit_memlock early to avoid
large malloc/free done by users who don't have sufficient limits.
Pre-allocation is done with vmalloc and alloc/free is done
via percpu_freelist. Here are performance numbers for different
pre-allocation algorithms that were implemented, but discarded
in favor of percpu_freelist:
1 cpu:
pcpu_ida 2.1M
pcpu_ida nolock 2.3M
bt 2.4M
kmalloc 1.8M
hlist+spinlock 2.3M
pcpu_freelist 2.6M
4 cpu:
pcpu_ida 1.5M
pcpu_ida nolock 1.8M
bt w/smp_align 1.7M
bt no/smp_align 1.1M
kmalloc 0.7M
hlist+spinlock 0.2M
pcpu_freelist 2.0M
8 cpu:
pcpu_ida 0.7M
bt w/smp_align 0.8M
kmalloc 0.4M
pcpu_freelist 1.5M
32 cpu:
kmalloc 0.13M
pcpu_freelist 0.49M
pcpu_ida nolock is a modified percpu_ida algorithm without
percpu_ida_cpu locks and without cross-cpu tag stealing.
It's faster than existing percpu_ida, but not as fast as pcpu_freelist.
bt is a variant of block/blk-mq-tag.c simlified and customized
for bpf use case. bt w/smp_align is using cache line for every 'long'
(similar to blk-mq-tag). bt no/smp_align allocates 'long'
bitmasks continuously to save memory. It's comparable to percpu_ida
and in some cases faster, but slower than percpu_freelist
hlist+spinlock is the simplest free list with single spinlock.
As expeceted it has very bad scaling in SMP.
kmalloc is existing implementation which is still available via
BPF_F_NO_PREALLOC flag. It's significantly slower in single cpu and
in 8 cpu setup it's 3 times slower than pre-allocation with pcpu_freelist,
but saves memory, so in cases where map->max_entries can be large
and number of map update/delete per second is low, it may make
sense to use it.
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2016-03-08 13:57:15 +08:00
|
|
|
/* iterated over all buckets and all elements */
|
2014-11-14 09:36:45 +08:00
|
|
|
return -ENOENT;
|
|
|
|
}
|
|
|
|
|
bpf: pre-allocate hash map elements
If kprobe is placed on spin_unlock then calling kmalloc/kfree from
bpf programs is not safe, since the following dead lock is possible:
kfree->spin_lock(kmem_cache_node->lock)...spin_unlock->kprobe->
bpf_prog->map_update->kmalloc->spin_lock(of the same kmem_cache_node->lock)
and deadlocks.
The following solutions were considered and some implemented, but
eventually discarded
- kmem_cache_create for every map
- add recursion check to slow-path of slub
- use reserved memory in bpf_map_update for in_irq or in preempt_disabled
- kmalloc via irq_work
At the end pre-allocation of all map elements turned out to be the simplest
solution and since the user is charged upfront for all the memory, such
pre-allocation doesn't affect the user space visible behavior.
Since it's impossible to tell whether kprobe is triggered in a safe
location from kmalloc point of view, use pre-allocation by default
and introduce new BPF_F_NO_PREALLOC flag.
While testing of per-cpu hash maps it was discovered
that alloc_percpu(GFP_ATOMIC) has odd corner cases and often
fails to allocate memory even when 90% of it is free.
The pre-allocation of per-cpu hash elements solves this problem as well.
Turned out that bpf_map_update() quickly followed by
bpf_map_lookup()+bpf_map_delete() is very common pattern used
in many of iovisor/bcc/tools, so there is additional benefit of
pre-allocation, since such use cases are must faster.
Since all hash map elements are now pre-allocated we can remove
atomic increment of htab->count and save few more cycles.
Also add bpf_map_precharge_memlock() to check rlimit_memlock early to avoid
large malloc/free done by users who don't have sufficient limits.
Pre-allocation is done with vmalloc and alloc/free is done
via percpu_freelist. Here are performance numbers for different
pre-allocation algorithms that were implemented, but discarded
in favor of percpu_freelist:
1 cpu:
pcpu_ida 2.1M
pcpu_ida nolock 2.3M
bt 2.4M
kmalloc 1.8M
hlist+spinlock 2.3M
pcpu_freelist 2.6M
4 cpu:
pcpu_ida 1.5M
pcpu_ida nolock 1.8M
bt w/smp_align 1.7M
bt no/smp_align 1.1M
kmalloc 0.7M
hlist+spinlock 0.2M
pcpu_freelist 2.0M
8 cpu:
pcpu_ida 0.7M
bt w/smp_align 0.8M
kmalloc 0.4M
pcpu_freelist 1.5M
32 cpu:
kmalloc 0.13M
pcpu_freelist 0.49M
pcpu_ida nolock is a modified percpu_ida algorithm without
percpu_ida_cpu locks and without cross-cpu tag stealing.
It's faster than existing percpu_ida, but not as fast as pcpu_freelist.
bt is a variant of block/blk-mq-tag.c simlified and customized
for bpf use case. bt w/smp_align is using cache line for every 'long'
(similar to blk-mq-tag). bt no/smp_align allocates 'long'
bitmasks continuously to save memory. It's comparable to percpu_ida
and in some cases faster, but slower than percpu_freelist
hlist+spinlock is the simplest free list with single spinlock.
As expeceted it has very bad scaling in SMP.
kmalloc is existing implementation which is still available via
BPF_F_NO_PREALLOC flag. It's significantly slower in single cpu and
in 8 cpu setup it's 3 times slower than pre-allocation with pcpu_freelist,
but saves memory, so in cases where map->max_entries can be large
and number of map update/delete per second is low, it may make
sense to use it.
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2016-03-08 13:57:15 +08:00
|
|
|
static void htab_elem_free(struct bpf_htab *htab, struct htab_elem *l)
|
2016-02-02 14:39:53 +08:00
|
|
|
{
|
bpf: pre-allocate hash map elements
If kprobe is placed on spin_unlock then calling kmalloc/kfree from
bpf programs is not safe, since the following dead lock is possible:
kfree->spin_lock(kmem_cache_node->lock)...spin_unlock->kprobe->
bpf_prog->map_update->kmalloc->spin_lock(of the same kmem_cache_node->lock)
and deadlocks.
The following solutions were considered and some implemented, but
eventually discarded
- kmem_cache_create for every map
- add recursion check to slow-path of slub
- use reserved memory in bpf_map_update for in_irq or in preempt_disabled
- kmalloc via irq_work
At the end pre-allocation of all map elements turned out to be the simplest
solution and since the user is charged upfront for all the memory, such
pre-allocation doesn't affect the user space visible behavior.
Since it's impossible to tell whether kprobe is triggered in a safe
location from kmalloc point of view, use pre-allocation by default
and introduce new BPF_F_NO_PREALLOC flag.
While testing of per-cpu hash maps it was discovered
that alloc_percpu(GFP_ATOMIC) has odd corner cases and often
fails to allocate memory even when 90% of it is free.
The pre-allocation of per-cpu hash elements solves this problem as well.
Turned out that bpf_map_update() quickly followed by
bpf_map_lookup()+bpf_map_delete() is very common pattern used
in many of iovisor/bcc/tools, so there is additional benefit of
pre-allocation, since such use cases are must faster.
Since all hash map elements are now pre-allocated we can remove
atomic increment of htab->count and save few more cycles.
Also add bpf_map_precharge_memlock() to check rlimit_memlock early to avoid
large malloc/free done by users who don't have sufficient limits.
Pre-allocation is done with vmalloc and alloc/free is done
via percpu_freelist. Here are performance numbers for different
pre-allocation algorithms that were implemented, but discarded
in favor of percpu_freelist:
1 cpu:
pcpu_ida 2.1M
pcpu_ida nolock 2.3M
bt 2.4M
kmalloc 1.8M
hlist+spinlock 2.3M
pcpu_freelist 2.6M
4 cpu:
pcpu_ida 1.5M
pcpu_ida nolock 1.8M
bt w/smp_align 1.7M
bt no/smp_align 1.1M
kmalloc 0.7M
hlist+spinlock 0.2M
pcpu_freelist 2.0M
8 cpu:
pcpu_ida 0.7M
bt w/smp_align 0.8M
kmalloc 0.4M
pcpu_freelist 1.5M
32 cpu:
kmalloc 0.13M
pcpu_freelist 0.49M
pcpu_ida nolock is a modified percpu_ida algorithm without
percpu_ida_cpu locks and without cross-cpu tag stealing.
It's faster than existing percpu_ida, but not as fast as pcpu_freelist.
bt is a variant of block/blk-mq-tag.c simlified and customized
for bpf use case. bt w/smp_align is using cache line for every 'long'
(similar to blk-mq-tag). bt no/smp_align allocates 'long'
bitmasks continuously to save memory. It's comparable to percpu_ida
and in some cases faster, but slower than percpu_freelist
hlist+spinlock is the simplest free list with single spinlock.
As expeceted it has very bad scaling in SMP.
kmalloc is existing implementation which is still available via
BPF_F_NO_PREALLOC flag. It's significantly slower in single cpu and
in 8 cpu setup it's 3 times slower than pre-allocation with pcpu_freelist,
but saves memory, so in cases where map->max_entries can be large
and number of map update/delete per second is low, it may make
sense to use it.
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2016-03-08 13:57:15 +08:00
|
|
|
if (htab->map.map_type == BPF_MAP_TYPE_PERCPU_HASH)
|
|
|
|
free_percpu(htab_elem_get_ptr(l, htab->map.key_size));
|
2016-02-02 14:39:53 +08:00
|
|
|
kfree(l);
|
|
|
|
}
|
|
|
|
|
bpf: pre-allocate hash map elements
If kprobe is placed on spin_unlock then calling kmalloc/kfree from
bpf programs is not safe, since the following dead lock is possible:
kfree->spin_lock(kmem_cache_node->lock)...spin_unlock->kprobe->
bpf_prog->map_update->kmalloc->spin_lock(of the same kmem_cache_node->lock)
and deadlocks.
The following solutions were considered and some implemented, but
eventually discarded
- kmem_cache_create for every map
- add recursion check to slow-path of slub
- use reserved memory in bpf_map_update for in_irq or in preempt_disabled
- kmalloc via irq_work
At the end pre-allocation of all map elements turned out to be the simplest
solution and since the user is charged upfront for all the memory, such
pre-allocation doesn't affect the user space visible behavior.
Since it's impossible to tell whether kprobe is triggered in a safe
location from kmalloc point of view, use pre-allocation by default
and introduce new BPF_F_NO_PREALLOC flag.
While testing of per-cpu hash maps it was discovered
that alloc_percpu(GFP_ATOMIC) has odd corner cases and often
fails to allocate memory even when 90% of it is free.
The pre-allocation of per-cpu hash elements solves this problem as well.
Turned out that bpf_map_update() quickly followed by
bpf_map_lookup()+bpf_map_delete() is very common pattern used
in many of iovisor/bcc/tools, so there is additional benefit of
pre-allocation, since such use cases are must faster.
Since all hash map elements are now pre-allocated we can remove
atomic increment of htab->count and save few more cycles.
Also add bpf_map_precharge_memlock() to check rlimit_memlock early to avoid
large malloc/free done by users who don't have sufficient limits.
Pre-allocation is done with vmalloc and alloc/free is done
via percpu_freelist. Here are performance numbers for different
pre-allocation algorithms that were implemented, but discarded
in favor of percpu_freelist:
1 cpu:
pcpu_ida 2.1M
pcpu_ida nolock 2.3M
bt 2.4M
kmalloc 1.8M
hlist+spinlock 2.3M
pcpu_freelist 2.6M
4 cpu:
pcpu_ida 1.5M
pcpu_ida nolock 1.8M
bt w/smp_align 1.7M
bt no/smp_align 1.1M
kmalloc 0.7M
hlist+spinlock 0.2M
pcpu_freelist 2.0M
8 cpu:
pcpu_ida 0.7M
bt w/smp_align 0.8M
kmalloc 0.4M
pcpu_freelist 1.5M
32 cpu:
kmalloc 0.13M
pcpu_freelist 0.49M
pcpu_ida nolock is a modified percpu_ida algorithm without
percpu_ida_cpu locks and without cross-cpu tag stealing.
It's faster than existing percpu_ida, but not as fast as pcpu_freelist.
bt is a variant of block/blk-mq-tag.c simlified and customized
for bpf use case. bt w/smp_align is using cache line for every 'long'
(similar to blk-mq-tag). bt no/smp_align allocates 'long'
bitmasks continuously to save memory. It's comparable to percpu_ida
and in some cases faster, but slower than percpu_freelist
hlist+spinlock is the simplest free list with single spinlock.
As expeceted it has very bad scaling in SMP.
kmalloc is existing implementation which is still available via
BPF_F_NO_PREALLOC flag. It's significantly slower in single cpu and
in 8 cpu setup it's 3 times slower than pre-allocation with pcpu_freelist,
but saves memory, so in cases where map->max_entries can be large
and number of map update/delete per second is low, it may make
sense to use it.
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2016-03-08 13:57:15 +08:00
|
|
|
static void htab_elem_free_rcu(struct rcu_head *head)
|
2016-02-02 14:39:53 +08:00
|
|
|
{
|
|
|
|
struct htab_elem *l = container_of(head, struct htab_elem, rcu);
|
bpf: pre-allocate hash map elements
If kprobe is placed on spin_unlock then calling kmalloc/kfree from
bpf programs is not safe, since the following dead lock is possible:
kfree->spin_lock(kmem_cache_node->lock)...spin_unlock->kprobe->
bpf_prog->map_update->kmalloc->spin_lock(of the same kmem_cache_node->lock)
and deadlocks.
The following solutions were considered and some implemented, but
eventually discarded
- kmem_cache_create for every map
- add recursion check to slow-path of slub
- use reserved memory in bpf_map_update for in_irq or in preempt_disabled
- kmalloc via irq_work
At the end pre-allocation of all map elements turned out to be the simplest
solution and since the user is charged upfront for all the memory, such
pre-allocation doesn't affect the user space visible behavior.
Since it's impossible to tell whether kprobe is triggered in a safe
location from kmalloc point of view, use pre-allocation by default
and introduce new BPF_F_NO_PREALLOC flag.
While testing of per-cpu hash maps it was discovered
that alloc_percpu(GFP_ATOMIC) has odd corner cases and often
fails to allocate memory even when 90% of it is free.
The pre-allocation of per-cpu hash elements solves this problem as well.
Turned out that bpf_map_update() quickly followed by
bpf_map_lookup()+bpf_map_delete() is very common pattern used
in many of iovisor/bcc/tools, so there is additional benefit of
pre-allocation, since such use cases are must faster.
Since all hash map elements are now pre-allocated we can remove
atomic increment of htab->count and save few more cycles.
Also add bpf_map_precharge_memlock() to check rlimit_memlock early to avoid
large malloc/free done by users who don't have sufficient limits.
Pre-allocation is done with vmalloc and alloc/free is done
via percpu_freelist. Here are performance numbers for different
pre-allocation algorithms that were implemented, but discarded
in favor of percpu_freelist:
1 cpu:
pcpu_ida 2.1M
pcpu_ida nolock 2.3M
bt 2.4M
kmalloc 1.8M
hlist+spinlock 2.3M
pcpu_freelist 2.6M
4 cpu:
pcpu_ida 1.5M
pcpu_ida nolock 1.8M
bt w/smp_align 1.7M
bt no/smp_align 1.1M
kmalloc 0.7M
hlist+spinlock 0.2M
pcpu_freelist 2.0M
8 cpu:
pcpu_ida 0.7M
bt w/smp_align 0.8M
kmalloc 0.4M
pcpu_freelist 1.5M
32 cpu:
kmalloc 0.13M
pcpu_freelist 0.49M
pcpu_ida nolock is a modified percpu_ida algorithm without
percpu_ida_cpu locks and without cross-cpu tag stealing.
It's faster than existing percpu_ida, but not as fast as pcpu_freelist.
bt is a variant of block/blk-mq-tag.c simlified and customized
for bpf use case. bt w/smp_align is using cache line for every 'long'
(similar to blk-mq-tag). bt no/smp_align allocates 'long'
bitmasks continuously to save memory. It's comparable to percpu_ida
and in some cases faster, but slower than percpu_freelist
hlist+spinlock is the simplest free list with single spinlock.
As expeceted it has very bad scaling in SMP.
kmalloc is existing implementation which is still available via
BPF_F_NO_PREALLOC flag. It's significantly slower in single cpu and
in 8 cpu setup it's 3 times slower than pre-allocation with pcpu_freelist,
but saves memory, so in cases where map->max_entries can be large
and number of map update/delete per second is low, it may make
sense to use it.
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2016-03-08 13:57:15 +08:00
|
|
|
struct bpf_htab *htab = l->htab;
|
2016-02-02 14:39:53 +08:00
|
|
|
|
bpf: pre-allocate hash map elements
If kprobe is placed on spin_unlock then calling kmalloc/kfree from
bpf programs is not safe, since the following dead lock is possible:
kfree->spin_lock(kmem_cache_node->lock)...spin_unlock->kprobe->
bpf_prog->map_update->kmalloc->spin_lock(of the same kmem_cache_node->lock)
and deadlocks.
The following solutions were considered and some implemented, but
eventually discarded
- kmem_cache_create for every map
- add recursion check to slow-path of slub
- use reserved memory in bpf_map_update for in_irq or in preempt_disabled
- kmalloc via irq_work
At the end pre-allocation of all map elements turned out to be the simplest
solution and since the user is charged upfront for all the memory, such
pre-allocation doesn't affect the user space visible behavior.
Since it's impossible to tell whether kprobe is triggered in a safe
location from kmalloc point of view, use pre-allocation by default
and introduce new BPF_F_NO_PREALLOC flag.
While testing of per-cpu hash maps it was discovered
that alloc_percpu(GFP_ATOMIC) has odd corner cases and often
fails to allocate memory even when 90% of it is free.
The pre-allocation of per-cpu hash elements solves this problem as well.
Turned out that bpf_map_update() quickly followed by
bpf_map_lookup()+bpf_map_delete() is very common pattern used
in many of iovisor/bcc/tools, so there is additional benefit of
pre-allocation, since such use cases are must faster.
Since all hash map elements are now pre-allocated we can remove
atomic increment of htab->count and save few more cycles.
Also add bpf_map_precharge_memlock() to check rlimit_memlock early to avoid
large malloc/free done by users who don't have sufficient limits.
Pre-allocation is done with vmalloc and alloc/free is done
via percpu_freelist. Here are performance numbers for different
pre-allocation algorithms that were implemented, but discarded
in favor of percpu_freelist:
1 cpu:
pcpu_ida 2.1M
pcpu_ida nolock 2.3M
bt 2.4M
kmalloc 1.8M
hlist+spinlock 2.3M
pcpu_freelist 2.6M
4 cpu:
pcpu_ida 1.5M
pcpu_ida nolock 1.8M
bt w/smp_align 1.7M
bt no/smp_align 1.1M
kmalloc 0.7M
hlist+spinlock 0.2M
pcpu_freelist 2.0M
8 cpu:
pcpu_ida 0.7M
bt w/smp_align 0.8M
kmalloc 0.4M
pcpu_freelist 1.5M
32 cpu:
kmalloc 0.13M
pcpu_freelist 0.49M
pcpu_ida nolock is a modified percpu_ida algorithm without
percpu_ida_cpu locks and without cross-cpu tag stealing.
It's faster than existing percpu_ida, but not as fast as pcpu_freelist.
bt is a variant of block/blk-mq-tag.c simlified and customized
for bpf use case. bt w/smp_align is using cache line for every 'long'
(similar to blk-mq-tag). bt no/smp_align allocates 'long'
bitmasks continuously to save memory. It's comparable to percpu_ida
and in some cases faster, but slower than percpu_freelist
hlist+spinlock is the simplest free list with single spinlock.
As expeceted it has very bad scaling in SMP.
kmalloc is existing implementation which is still available via
BPF_F_NO_PREALLOC flag. It's significantly slower in single cpu and
in 8 cpu setup it's 3 times slower than pre-allocation with pcpu_freelist,
but saves memory, so in cases where map->max_entries can be large
and number of map update/delete per second is low, it may make
sense to use it.
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2016-03-08 13:57:15 +08:00
|
|
|
htab_elem_free(htab, l);
|
2016-02-02 14:39:53 +08:00
|
|
|
}
|
|
|
|
|
bpf: pre-allocate hash map elements
If kprobe is placed on spin_unlock then calling kmalloc/kfree from
bpf programs is not safe, since the following dead lock is possible:
kfree->spin_lock(kmem_cache_node->lock)...spin_unlock->kprobe->
bpf_prog->map_update->kmalloc->spin_lock(of the same kmem_cache_node->lock)
and deadlocks.
The following solutions were considered and some implemented, but
eventually discarded
- kmem_cache_create for every map
- add recursion check to slow-path of slub
- use reserved memory in bpf_map_update for in_irq or in preempt_disabled
- kmalloc via irq_work
At the end pre-allocation of all map elements turned out to be the simplest
solution and since the user is charged upfront for all the memory, such
pre-allocation doesn't affect the user space visible behavior.
Since it's impossible to tell whether kprobe is triggered in a safe
location from kmalloc point of view, use pre-allocation by default
and introduce new BPF_F_NO_PREALLOC flag.
While testing of per-cpu hash maps it was discovered
that alloc_percpu(GFP_ATOMIC) has odd corner cases and often
fails to allocate memory even when 90% of it is free.
The pre-allocation of per-cpu hash elements solves this problem as well.
Turned out that bpf_map_update() quickly followed by
bpf_map_lookup()+bpf_map_delete() is very common pattern used
in many of iovisor/bcc/tools, so there is additional benefit of
pre-allocation, since such use cases are must faster.
Since all hash map elements are now pre-allocated we can remove
atomic increment of htab->count and save few more cycles.
Also add bpf_map_precharge_memlock() to check rlimit_memlock early to avoid
large malloc/free done by users who don't have sufficient limits.
Pre-allocation is done with vmalloc and alloc/free is done
via percpu_freelist. Here are performance numbers for different
pre-allocation algorithms that were implemented, but discarded
in favor of percpu_freelist:
1 cpu:
pcpu_ida 2.1M
pcpu_ida nolock 2.3M
bt 2.4M
kmalloc 1.8M
hlist+spinlock 2.3M
pcpu_freelist 2.6M
4 cpu:
pcpu_ida 1.5M
pcpu_ida nolock 1.8M
bt w/smp_align 1.7M
bt no/smp_align 1.1M
kmalloc 0.7M
hlist+spinlock 0.2M
pcpu_freelist 2.0M
8 cpu:
pcpu_ida 0.7M
bt w/smp_align 0.8M
kmalloc 0.4M
pcpu_freelist 1.5M
32 cpu:
kmalloc 0.13M
pcpu_freelist 0.49M
pcpu_ida nolock is a modified percpu_ida algorithm without
percpu_ida_cpu locks and without cross-cpu tag stealing.
It's faster than existing percpu_ida, but not as fast as pcpu_freelist.
bt is a variant of block/blk-mq-tag.c simlified and customized
for bpf use case. bt w/smp_align is using cache line for every 'long'
(similar to blk-mq-tag). bt no/smp_align allocates 'long'
bitmasks continuously to save memory. It's comparable to percpu_ida
and in some cases faster, but slower than percpu_freelist
hlist+spinlock is the simplest free list with single spinlock.
As expeceted it has very bad scaling in SMP.
kmalloc is existing implementation which is still available via
BPF_F_NO_PREALLOC flag. It's significantly slower in single cpu and
in 8 cpu setup it's 3 times slower than pre-allocation with pcpu_freelist,
but saves memory, so in cases where map->max_entries can be large
and number of map update/delete per second is low, it may make
sense to use it.
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2016-03-08 13:57:15 +08:00
|
|
|
static void free_htab_elem(struct bpf_htab *htab, struct htab_elem *l)
|
2016-02-02 14:39:53 +08:00
|
|
|
{
|
2017-03-23 01:00:34 +08:00
|
|
|
struct bpf_map *map = &htab->map;
|
|
|
|
|
|
|
|
if (map->ops->map_fd_put_ptr) {
|
|
|
|
void *ptr = fd_htab_map_get_ptr(map, l);
|
|
|
|
|
|
|
|
map->ops->map_fd_put_ptr(ptr);
|
|
|
|
}
|
|
|
|
|
2017-03-22 10:05:04 +08:00
|
|
|
if (htab_is_prealloc(htab)) {
|
2019-01-31 10:12:43 +08:00
|
|
|
__pcpu_freelist_push(&htab->freelist, &l->fnode);
|
2016-02-02 14:39:53 +08:00
|
|
|
} else {
|
bpf: pre-allocate hash map elements
If kprobe is placed on spin_unlock then calling kmalloc/kfree from
bpf programs is not safe, since the following dead lock is possible:
kfree->spin_lock(kmem_cache_node->lock)...spin_unlock->kprobe->
bpf_prog->map_update->kmalloc->spin_lock(of the same kmem_cache_node->lock)
and deadlocks.
The following solutions were considered and some implemented, but
eventually discarded
- kmem_cache_create for every map
- add recursion check to slow-path of slub
- use reserved memory in bpf_map_update for in_irq or in preempt_disabled
- kmalloc via irq_work
At the end pre-allocation of all map elements turned out to be the simplest
solution and since the user is charged upfront for all the memory, such
pre-allocation doesn't affect the user space visible behavior.
Since it's impossible to tell whether kprobe is triggered in a safe
location from kmalloc point of view, use pre-allocation by default
and introduce new BPF_F_NO_PREALLOC flag.
While testing of per-cpu hash maps it was discovered
that alloc_percpu(GFP_ATOMIC) has odd corner cases and often
fails to allocate memory even when 90% of it is free.
The pre-allocation of per-cpu hash elements solves this problem as well.
Turned out that bpf_map_update() quickly followed by
bpf_map_lookup()+bpf_map_delete() is very common pattern used
in many of iovisor/bcc/tools, so there is additional benefit of
pre-allocation, since such use cases are must faster.
Since all hash map elements are now pre-allocated we can remove
atomic increment of htab->count and save few more cycles.
Also add bpf_map_precharge_memlock() to check rlimit_memlock early to avoid
large malloc/free done by users who don't have sufficient limits.
Pre-allocation is done with vmalloc and alloc/free is done
via percpu_freelist. Here are performance numbers for different
pre-allocation algorithms that were implemented, but discarded
in favor of percpu_freelist:
1 cpu:
pcpu_ida 2.1M
pcpu_ida nolock 2.3M
bt 2.4M
kmalloc 1.8M
hlist+spinlock 2.3M
pcpu_freelist 2.6M
4 cpu:
pcpu_ida 1.5M
pcpu_ida nolock 1.8M
bt w/smp_align 1.7M
bt no/smp_align 1.1M
kmalloc 0.7M
hlist+spinlock 0.2M
pcpu_freelist 2.0M
8 cpu:
pcpu_ida 0.7M
bt w/smp_align 0.8M
kmalloc 0.4M
pcpu_freelist 1.5M
32 cpu:
kmalloc 0.13M
pcpu_freelist 0.49M
pcpu_ida nolock is a modified percpu_ida algorithm without
percpu_ida_cpu locks and without cross-cpu tag stealing.
It's faster than existing percpu_ida, but not as fast as pcpu_freelist.
bt is a variant of block/blk-mq-tag.c simlified and customized
for bpf use case. bt w/smp_align is using cache line for every 'long'
(similar to blk-mq-tag). bt no/smp_align allocates 'long'
bitmasks continuously to save memory. It's comparable to percpu_ida
and in some cases faster, but slower than percpu_freelist
hlist+spinlock is the simplest free list with single spinlock.
As expeceted it has very bad scaling in SMP.
kmalloc is existing implementation which is still available via
BPF_F_NO_PREALLOC flag. It's significantly slower in single cpu and
in 8 cpu setup it's 3 times slower than pre-allocation with pcpu_freelist,
but saves memory, so in cases where map->max_entries can be large
and number of map update/delete per second is low, it may make
sense to use it.
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2016-03-08 13:57:15 +08:00
|
|
|
atomic_dec(&htab->count);
|
|
|
|
l->htab = htab;
|
|
|
|
call_rcu(&l->rcu, htab_elem_free_rcu);
|
2016-02-02 14:39:53 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2016-11-12 02:55:08 +08:00
|
|
|
static void pcpu_copy_value(struct bpf_htab *htab, void __percpu *pptr,
|
|
|
|
void *value, bool onallcpus)
|
|
|
|
{
|
|
|
|
if (!onallcpus) {
|
|
|
|
/* copy true value_size bytes */
|
|
|
|
memcpy(this_cpu_ptr(pptr), value, htab->map.value_size);
|
|
|
|
} else {
|
|
|
|
u32 size = round_up(htab->map.value_size, 8);
|
|
|
|
int off = 0, cpu;
|
|
|
|
|
|
|
|
for_each_possible_cpu(cpu) {
|
|
|
|
bpf_long_memcpy(per_cpu_ptr(pptr, cpu),
|
|
|
|
value + off, size);
|
|
|
|
off += size;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2017-08-23 06:06:09 +08:00
|
|
|
static bool fd_htab_map_needs_adjust(const struct bpf_htab *htab)
|
|
|
|
{
|
|
|
|
return htab->map.map_type == BPF_MAP_TYPE_HASH_OF_MAPS &&
|
|
|
|
BITS_PER_LONG == 64;
|
|
|
|
}
|
|
|
|
|
2016-02-02 14:39:53 +08:00
|
|
|
static struct htab_elem *alloc_htab_elem(struct bpf_htab *htab, void *key,
|
|
|
|
void *value, u32 key_size, u32 hash,
|
2016-08-06 05:01:27 +08:00
|
|
|
bool percpu, bool onallcpus,
|
2017-03-22 10:05:04 +08:00
|
|
|
struct htab_elem *old_elem)
|
2016-02-02 14:39:53 +08:00
|
|
|
{
|
2019-02-01 07:40:04 +08:00
|
|
|
u32 size = htab->map.value_size;
|
2017-03-22 10:05:04 +08:00
|
|
|
bool prealloc = htab_is_prealloc(htab);
|
|
|
|
struct htab_elem *l_new, **pl_new;
|
2016-02-02 14:39:53 +08:00
|
|
|
void __percpu *pptr;
|
|
|
|
|
bpf: pre-allocate hash map elements
If kprobe is placed on spin_unlock then calling kmalloc/kfree from
bpf programs is not safe, since the following dead lock is possible:
kfree->spin_lock(kmem_cache_node->lock)...spin_unlock->kprobe->
bpf_prog->map_update->kmalloc->spin_lock(of the same kmem_cache_node->lock)
and deadlocks.
The following solutions were considered and some implemented, but
eventually discarded
- kmem_cache_create for every map
- add recursion check to slow-path of slub
- use reserved memory in bpf_map_update for in_irq or in preempt_disabled
- kmalloc via irq_work
At the end pre-allocation of all map elements turned out to be the simplest
solution and since the user is charged upfront for all the memory, such
pre-allocation doesn't affect the user space visible behavior.
Since it's impossible to tell whether kprobe is triggered in a safe
location from kmalloc point of view, use pre-allocation by default
and introduce new BPF_F_NO_PREALLOC flag.
While testing of per-cpu hash maps it was discovered
that alloc_percpu(GFP_ATOMIC) has odd corner cases and often
fails to allocate memory even when 90% of it is free.
The pre-allocation of per-cpu hash elements solves this problem as well.
Turned out that bpf_map_update() quickly followed by
bpf_map_lookup()+bpf_map_delete() is very common pattern used
in many of iovisor/bcc/tools, so there is additional benefit of
pre-allocation, since such use cases are must faster.
Since all hash map elements are now pre-allocated we can remove
atomic increment of htab->count and save few more cycles.
Also add bpf_map_precharge_memlock() to check rlimit_memlock early to avoid
large malloc/free done by users who don't have sufficient limits.
Pre-allocation is done with vmalloc and alloc/free is done
via percpu_freelist. Here are performance numbers for different
pre-allocation algorithms that were implemented, but discarded
in favor of percpu_freelist:
1 cpu:
pcpu_ida 2.1M
pcpu_ida nolock 2.3M
bt 2.4M
kmalloc 1.8M
hlist+spinlock 2.3M
pcpu_freelist 2.6M
4 cpu:
pcpu_ida 1.5M
pcpu_ida nolock 1.8M
bt w/smp_align 1.7M
bt no/smp_align 1.1M
kmalloc 0.7M
hlist+spinlock 0.2M
pcpu_freelist 2.0M
8 cpu:
pcpu_ida 0.7M
bt w/smp_align 0.8M
kmalloc 0.4M
pcpu_freelist 1.5M
32 cpu:
kmalloc 0.13M
pcpu_freelist 0.49M
pcpu_ida nolock is a modified percpu_ida algorithm without
percpu_ida_cpu locks and without cross-cpu tag stealing.
It's faster than existing percpu_ida, but not as fast as pcpu_freelist.
bt is a variant of block/blk-mq-tag.c simlified and customized
for bpf use case. bt w/smp_align is using cache line for every 'long'
(similar to blk-mq-tag). bt no/smp_align allocates 'long'
bitmasks continuously to save memory. It's comparable to percpu_ida
and in some cases faster, but slower than percpu_freelist
hlist+spinlock is the simplest free list with single spinlock.
As expeceted it has very bad scaling in SMP.
kmalloc is existing implementation which is still available via
BPF_F_NO_PREALLOC flag. It's significantly slower in single cpu and
in 8 cpu setup it's 3 times slower than pre-allocation with pcpu_freelist,
but saves memory, so in cases where map->max_entries can be large
and number of map update/delete per second is low, it may make
sense to use it.
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2016-03-08 13:57:15 +08:00
|
|
|
if (prealloc) {
|
2017-03-22 10:05:04 +08:00
|
|
|
if (old_elem) {
|
|
|
|
/* if we're updating the existing element,
|
|
|
|
* use per-cpu extra elems to avoid freelist_pop/push
|
|
|
|
*/
|
|
|
|
pl_new = this_cpu_ptr(htab->extra_elems);
|
|
|
|
l_new = *pl_new;
|
|
|
|
*pl_new = old_elem;
|
|
|
|
} else {
|
|
|
|
struct pcpu_freelist_node *l;
|
2017-03-08 12:00:12 +08:00
|
|
|
|
2019-01-31 10:12:43 +08:00
|
|
|
l = __pcpu_freelist_pop(&htab->freelist);
|
2017-03-22 10:05:04 +08:00
|
|
|
if (!l)
|
|
|
|
return ERR_PTR(-E2BIG);
|
2017-03-08 12:00:12 +08:00
|
|
|
l_new = container_of(l, struct htab_elem, fnode);
|
bpf: pre-allocate hash map elements
If kprobe is placed on spin_unlock then calling kmalloc/kfree from
bpf programs is not safe, since the following dead lock is possible:
kfree->spin_lock(kmem_cache_node->lock)...spin_unlock->kprobe->
bpf_prog->map_update->kmalloc->spin_lock(of the same kmem_cache_node->lock)
and deadlocks.
The following solutions were considered and some implemented, but
eventually discarded
- kmem_cache_create for every map
- add recursion check to slow-path of slub
- use reserved memory in bpf_map_update for in_irq or in preempt_disabled
- kmalloc via irq_work
At the end pre-allocation of all map elements turned out to be the simplest
solution and since the user is charged upfront for all the memory, such
pre-allocation doesn't affect the user space visible behavior.
Since it's impossible to tell whether kprobe is triggered in a safe
location from kmalloc point of view, use pre-allocation by default
and introduce new BPF_F_NO_PREALLOC flag.
While testing of per-cpu hash maps it was discovered
that alloc_percpu(GFP_ATOMIC) has odd corner cases and often
fails to allocate memory even when 90% of it is free.
The pre-allocation of per-cpu hash elements solves this problem as well.
Turned out that bpf_map_update() quickly followed by
bpf_map_lookup()+bpf_map_delete() is very common pattern used
in many of iovisor/bcc/tools, so there is additional benefit of
pre-allocation, since such use cases are must faster.
Since all hash map elements are now pre-allocated we can remove
atomic increment of htab->count and save few more cycles.
Also add bpf_map_precharge_memlock() to check rlimit_memlock early to avoid
large malloc/free done by users who don't have sufficient limits.
Pre-allocation is done with vmalloc and alloc/free is done
via percpu_freelist. Here are performance numbers for different
pre-allocation algorithms that were implemented, but discarded
in favor of percpu_freelist:
1 cpu:
pcpu_ida 2.1M
pcpu_ida nolock 2.3M
bt 2.4M
kmalloc 1.8M
hlist+spinlock 2.3M
pcpu_freelist 2.6M
4 cpu:
pcpu_ida 1.5M
pcpu_ida nolock 1.8M
bt w/smp_align 1.7M
bt no/smp_align 1.1M
kmalloc 0.7M
hlist+spinlock 0.2M
pcpu_freelist 2.0M
8 cpu:
pcpu_ida 0.7M
bt w/smp_align 0.8M
kmalloc 0.4M
pcpu_freelist 1.5M
32 cpu:
kmalloc 0.13M
pcpu_freelist 0.49M
pcpu_ida nolock is a modified percpu_ida algorithm without
percpu_ida_cpu locks and without cross-cpu tag stealing.
It's faster than existing percpu_ida, but not as fast as pcpu_freelist.
bt is a variant of block/blk-mq-tag.c simlified and customized
for bpf use case. bt w/smp_align is using cache line for every 'long'
(similar to blk-mq-tag). bt no/smp_align allocates 'long'
bitmasks continuously to save memory. It's comparable to percpu_ida
and in some cases faster, but slower than percpu_freelist
hlist+spinlock is the simplest free list with single spinlock.
As expeceted it has very bad scaling in SMP.
kmalloc is existing implementation which is still available via
BPF_F_NO_PREALLOC flag. It's significantly slower in single cpu and
in 8 cpu setup it's 3 times slower than pre-allocation with pcpu_freelist,
but saves memory, so in cases where map->max_entries can be large
and number of map update/delete per second is low, it may make
sense to use it.
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2016-03-08 13:57:15 +08:00
|
|
|
}
|
2016-08-06 05:01:27 +08:00
|
|
|
} else {
|
2017-03-22 10:05:04 +08:00
|
|
|
if (atomic_inc_return(&htab->count) > htab->map.max_entries)
|
|
|
|
if (!old_elem) {
|
|
|
|
/* when map is full and update() is replacing
|
|
|
|
* old element, it's ok to allocate, since
|
|
|
|
* old element will be freed immediately.
|
|
|
|
* Otherwise return an error
|
|
|
|
*/
|
2018-06-29 20:48:20 +08:00
|
|
|
l_new = ERR_PTR(-E2BIG);
|
|
|
|
goto dec_count;
|
2017-03-22 10:05:04 +08:00
|
|
|
}
|
2017-08-19 02:28:00 +08:00
|
|
|
l_new = kmalloc_node(htab->elem_size, GFP_ATOMIC | __GFP_NOWARN,
|
|
|
|
htab->map.numa_node);
|
2018-06-29 20:48:20 +08:00
|
|
|
if (!l_new) {
|
|
|
|
l_new = ERR_PTR(-ENOMEM);
|
|
|
|
goto dec_count;
|
|
|
|
}
|
2019-02-01 07:40:04 +08:00
|
|
|
check_and_init_map_lock(&htab->map,
|
|
|
|
l_new->key + round_up(key_size, 8));
|
bpf: pre-allocate hash map elements
If kprobe is placed on spin_unlock then calling kmalloc/kfree from
bpf programs is not safe, since the following dead lock is possible:
kfree->spin_lock(kmem_cache_node->lock)...spin_unlock->kprobe->
bpf_prog->map_update->kmalloc->spin_lock(of the same kmem_cache_node->lock)
and deadlocks.
The following solutions were considered and some implemented, but
eventually discarded
- kmem_cache_create for every map
- add recursion check to slow-path of slub
- use reserved memory in bpf_map_update for in_irq or in preempt_disabled
- kmalloc via irq_work
At the end pre-allocation of all map elements turned out to be the simplest
solution and since the user is charged upfront for all the memory, such
pre-allocation doesn't affect the user space visible behavior.
Since it's impossible to tell whether kprobe is triggered in a safe
location from kmalloc point of view, use pre-allocation by default
and introduce new BPF_F_NO_PREALLOC flag.
While testing of per-cpu hash maps it was discovered
that alloc_percpu(GFP_ATOMIC) has odd corner cases and often
fails to allocate memory even when 90% of it is free.
The pre-allocation of per-cpu hash elements solves this problem as well.
Turned out that bpf_map_update() quickly followed by
bpf_map_lookup()+bpf_map_delete() is very common pattern used
in many of iovisor/bcc/tools, so there is additional benefit of
pre-allocation, since such use cases are must faster.
Since all hash map elements are now pre-allocated we can remove
atomic increment of htab->count and save few more cycles.
Also add bpf_map_precharge_memlock() to check rlimit_memlock early to avoid
large malloc/free done by users who don't have sufficient limits.
Pre-allocation is done with vmalloc and alloc/free is done
via percpu_freelist. Here are performance numbers for different
pre-allocation algorithms that were implemented, but discarded
in favor of percpu_freelist:
1 cpu:
pcpu_ida 2.1M
pcpu_ida nolock 2.3M
bt 2.4M
kmalloc 1.8M
hlist+spinlock 2.3M
pcpu_freelist 2.6M
4 cpu:
pcpu_ida 1.5M
pcpu_ida nolock 1.8M
bt w/smp_align 1.7M
bt no/smp_align 1.1M
kmalloc 0.7M
hlist+spinlock 0.2M
pcpu_freelist 2.0M
8 cpu:
pcpu_ida 0.7M
bt w/smp_align 0.8M
kmalloc 0.4M
pcpu_freelist 1.5M
32 cpu:
kmalloc 0.13M
pcpu_freelist 0.49M
pcpu_ida nolock is a modified percpu_ida algorithm without
percpu_ida_cpu locks and without cross-cpu tag stealing.
It's faster than existing percpu_ida, but not as fast as pcpu_freelist.
bt is a variant of block/blk-mq-tag.c simlified and customized
for bpf use case. bt w/smp_align is using cache line for every 'long'
(similar to blk-mq-tag). bt no/smp_align allocates 'long'
bitmasks continuously to save memory. It's comparable to percpu_ida
and in some cases faster, but slower than percpu_freelist
hlist+spinlock is the simplest free list with single spinlock.
As expeceted it has very bad scaling in SMP.
kmalloc is existing implementation which is still available via
BPF_F_NO_PREALLOC flag. It's significantly slower in single cpu and
in 8 cpu setup it's 3 times slower than pre-allocation with pcpu_freelist,
but saves memory, so in cases where map->max_entries can be large
and number of map update/delete per second is low, it may make
sense to use it.
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2016-03-08 13:57:15 +08:00
|
|
|
}
|
2016-02-02 14:39:53 +08:00
|
|
|
|
|
|
|
memcpy(l_new->key, key, key_size);
|
|
|
|
if (percpu) {
|
2019-02-01 07:40:04 +08:00
|
|
|
size = round_up(size, 8);
|
bpf: pre-allocate hash map elements
If kprobe is placed on spin_unlock then calling kmalloc/kfree from
bpf programs is not safe, since the following dead lock is possible:
kfree->spin_lock(kmem_cache_node->lock)...spin_unlock->kprobe->
bpf_prog->map_update->kmalloc->spin_lock(of the same kmem_cache_node->lock)
and deadlocks.
The following solutions were considered and some implemented, but
eventually discarded
- kmem_cache_create for every map
- add recursion check to slow-path of slub
- use reserved memory in bpf_map_update for in_irq or in preempt_disabled
- kmalloc via irq_work
At the end pre-allocation of all map elements turned out to be the simplest
solution and since the user is charged upfront for all the memory, such
pre-allocation doesn't affect the user space visible behavior.
Since it's impossible to tell whether kprobe is triggered in a safe
location from kmalloc point of view, use pre-allocation by default
and introduce new BPF_F_NO_PREALLOC flag.
While testing of per-cpu hash maps it was discovered
that alloc_percpu(GFP_ATOMIC) has odd corner cases and often
fails to allocate memory even when 90% of it is free.
The pre-allocation of per-cpu hash elements solves this problem as well.
Turned out that bpf_map_update() quickly followed by
bpf_map_lookup()+bpf_map_delete() is very common pattern used
in many of iovisor/bcc/tools, so there is additional benefit of
pre-allocation, since such use cases are must faster.
Since all hash map elements are now pre-allocated we can remove
atomic increment of htab->count and save few more cycles.
Also add bpf_map_precharge_memlock() to check rlimit_memlock early to avoid
large malloc/free done by users who don't have sufficient limits.
Pre-allocation is done with vmalloc and alloc/free is done
via percpu_freelist. Here are performance numbers for different
pre-allocation algorithms that were implemented, but discarded
in favor of percpu_freelist:
1 cpu:
pcpu_ida 2.1M
pcpu_ida nolock 2.3M
bt 2.4M
kmalloc 1.8M
hlist+spinlock 2.3M
pcpu_freelist 2.6M
4 cpu:
pcpu_ida 1.5M
pcpu_ida nolock 1.8M
bt w/smp_align 1.7M
bt no/smp_align 1.1M
kmalloc 0.7M
hlist+spinlock 0.2M
pcpu_freelist 2.0M
8 cpu:
pcpu_ida 0.7M
bt w/smp_align 0.8M
kmalloc 0.4M
pcpu_freelist 1.5M
32 cpu:
kmalloc 0.13M
pcpu_freelist 0.49M
pcpu_ida nolock is a modified percpu_ida algorithm without
percpu_ida_cpu locks and without cross-cpu tag stealing.
It's faster than existing percpu_ida, but not as fast as pcpu_freelist.
bt is a variant of block/blk-mq-tag.c simlified and customized
for bpf use case. bt w/smp_align is using cache line for every 'long'
(similar to blk-mq-tag). bt no/smp_align allocates 'long'
bitmasks continuously to save memory. It's comparable to percpu_ida
and in some cases faster, but slower than percpu_freelist
hlist+spinlock is the simplest free list with single spinlock.
As expeceted it has very bad scaling in SMP.
kmalloc is existing implementation which is still available via
BPF_F_NO_PREALLOC flag. It's significantly slower in single cpu and
in 8 cpu setup it's 3 times slower than pre-allocation with pcpu_freelist,
but saves memory, so in cases where map->max_entries can be large
and number of map update/delete per second is low, it may make
sense to use it.
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2016-03-08 13:57:15 +08:00
|
|
|
if (prealloc) {
|
|
|
|
pptr = htab_elem_get_ptr(l_new, key_size);
|
|
|
|
} else {
|
|
|
|
/* alloc_percpu zero-fills */
|
|
|
|
pptr = __alloc_percpu_gfp(size, 8,
|
|
|
|
GFP_ATOMIC | __GFP_NOWARN);
|
|
|
|
if (!pptr) {
|
|
|
|
kfree(l_new);
|
2018-06-29 20:48:20 +08:00
|
|
|
l_new = ERR_PTR(-ENOMEM);
|
|
|
|
goto dec_count;
|
bpf: pre-allocate hash map elements
If kprobe is placed on spin_unlock then calling kmalloc/kfree from
bpf programs is not safe, since the following dead lock is possible:
kfree->spin_lock(kmem_cache_node->lock)...spin_unlock->kprobe->
bpf_prog->map_update->kmalloc->spin_lock(of the same kmem_cache_node->lock)
and deadlocks.
The following solutions were considered and some implemented, but
eventually discarded
- kmem_cache_create for every map
- add recursion check to slow-path of slub
- use reserved memory in bpf_map_update for in_irq or in preempt_disabled
- kmalloc via irq_work
At the end pre-allocation of all map elements turned out to be the simplest
solution and since the user is charged upfront for all the memory, such
pre-allocation doesn't affect the user space visible behavior.
Since it's impossible to tell whether kprobe is triggered in a safe
location from kmalloc point of view, use pre-allocation by default
and introduce new BPF_F_NO_PREALLOC flag.
While testing of per-cpu hash maps it was discovered
that alloc_percpu(GFP_ATOMIC) has odd corner cases and often
fails to allocate memory even when 90% of it is free.
The pre-allocation of per-cpu hash elements solves this problem as well.
Turned out that bpf_map_update() quickly followed by
bpf_map_lookup()+bpf_map_delete() is very common pattern used
in many of iovisor/bcc/tools, so there is additional benefit of
pre-allocation, since such use cases are must faster.
Since all hash map elements are now pre-allocated we can remove
atomic increment of htab->count and save few more cycles.
Also add bpf_map_precharge_memlock() to check rlimit_memlock early to avoid
large malloc/free done by users who don't have sufficient limits.
Pre-allocation is done with vmalloc and alloc/free is done
via percpu_freelist. Here are performance numbers for different
pre-allocation algorithms that were implemented, but discarded
in favor of percpu_freelist:
1 cpu:
pcpu_ida 2.1M
pcpu_ida nolock 2.3M
bt 2.4M
kmalloc 1.8M
hlist+spinlock 2.3M
pcpu_freelist 2.6M
4 cpu:
pcpu_ida 1.5M
pcpu_ida nolock 1.8M
bt w/smp_align 1.7M
bt no/smp_align 1.1M
kmalloc 0.7M
hlist+spinlock 0.2M
pcpu_freelist 2.0M
8 cpu:
pcpu_ida 0.7M
bt w/smp_align 0.8M
kmalloc 0.4M
pcpu_freelist 1.5M
32 cpu:
kmalloc 0.13M
pcpu_freelist 0.49M
pcpu_ida nolock is a modified percpu_ida algorithm without
percpu_ida_cpu locks and without cross-cpu tag stealing.
It's faster than existing percpu_ida, but not as fast as pcpu_freelist.
bt is a variant of block/blk-mq-tag.c simlified and customized
for bpf use case. bt w/smp_align is using cache line for every 'long'
(similar to blk-mq-tag). bt no/smp_align allocates 'long'
bitmasks continuously to save memory. It's comparable to percpu_ida
and in some cases faster, but slower than percpu_freelist
hlist+spinlock is the simplest free list with single spinlock.
As expeceted it has very bad scaling in SMP.
kmalloc is existing implementation which is still available via
BPF_F_NO_PREALLOC flag. It's significantly slower in single cpu and
in 8 cpu setup it's 3 times slower than pre-allocation with pcpu_freelist,
but saves memory, so in cases where map->max_entries can be large
and number of map update/delete per second is low, it may make
sense to use it.
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2016-03-08 13:57:15 +08:00
|
|
|
}
|
2016-02-02 14:39:53 +08:00
|
|
|
}
|
|
|
|
|
2016-11-12 02:55:08 +08:00
|
|
|
pcpu_copy_value(htab, pptr, value, onallcpus);
|
bpf: add lookup/update support for per-cpu hash and array maps
The functions bpf_map_lookup_elem(map, key, value) and
bpf_map_update_elem(map, key, value, flags) need to get/set
values from all-cpus for per-cpu hash and array maps,
so that user space can aggregate/update them as necessary.
Example of single counter aggregation in user space:
unsigned int nr_cpus = sysconf(_SC_NPROCESSORS_CONF);
long values[nr_cpus];
long value = 0;
bpf_lookup_elem(fd, key, values);
for (i = 0; i < nr_cpus; i++)
value += values[i];
The user space must provide round_up(value_size, 8) * nr_cpus
array to get/set values, since kernel will use 'long' copy
of per-cpu values to try to copy good counters atomically.
It's a best-effort, since bpf programs and user space are racing
to access the same memory.
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2016-02-02 14:39:55 +08:00
|
|
|
|
bpf: pre-allocate hash map elements
If kprobe is placed on spin_unlock then calling kmalloc/kfree from
bpf programs is not safe, since the following dead lock is possible:
kfree->spin_lock(kmem_cache_node->lock)...spin_unlock->kprobe->
bpf_prog->map_update->kmalloc->spin_lock(of the same kmem_cache_node->lock)
and deadlocks.
The following solutions were considered and some implemented, but
eventually discarded
- kmem_cache_create for every map
- add recursion check to slow-path of slub
- use reserved memory in bpf_map_update for in_irq or in preempt_disabled
- kmalloc via irq_work
At the end pre-allocation of all map elements turned out to be the simplest
solution and since the user is charged upfront for all the memory, such
pre-allocation doesn't affect the user space visible behavior.
Since it's impossible to tell whether kprobe is triggered in a safe
location from kmalloc point of view, use pre-allocation by default
and introduce new BPF_F_NO_PREALLOC flag.
While testing of per-cpu hash maps it was discovered
that alloc_percpu(GFP_ATOMIC) has odd corner cases and often
fails to allocate memory even when 90% of it is free.
The pre-allocation of per-cpu hash elements solves this problem as well.
Turned out that bpf_map_update() quickly followed by
bpf_map_lookup()+bpf_map_delete() is very common pattern used
in many of iovisor/bcc/tools, so there is additional benefit of
pre-allocation, since such use cases are must faster.
Since all hash map elements are now pre-allocated we can remove
atomic increment of htab->count and save few more cycles.
Also add bpf_map_precharge_memlock() to check rlimit_memlock early to avoid
large malloc/free done by users who don't have sufficient limits.
Pre-allocation is done with vmalloc and alloc/free is done
via percpu_freelist. Here are performance numbers for different
pre-allocation algorithms that were implemented, but discarded
in favor of percpu_freelist:
1 cpu:
pcpu_ida 2.1M
pcpu_ida nolock 2.3M
bt 2.4M
kmalloc 1.8M
hlist+spinlock 2.3M
pcpu_freelist 2.6M
4 cpu:
pcpu_ida 1.5M
pcpu_ida nolock 1.8M
bt w/smp_align 1.7M
bt no/smp_align 1.1M
kmalloc 0.7M
hlist+spinlock 0.2M
pcpu_freelist 2.0M
8 cpu:
pcpu_ida 0.7M
bt w/smp_align 0.8M
kmalloc 0.4M
pcpu_freelist 1.5M
32 cpu:
kmalloc 0.13M
pcpu_freelist 0.49M
pcpu_ida nolock is a modified percpu_ida algorithm without
percpu_ida_cpu locks and without cross-cpu tag stealing.
It's faster than existing percpu_ida, but not as fast as pcpu_freelist.
bt is a variant of block/blk-mq-tag.c simlified and customized
for bpf use case. bt w/smp_align is using cache line for every 'long'
(similar to blk-mq-tag). bt no/smp_align allocates 'long'
bitmasks continuously to save memory. It's comparable to percpu_ida
and in some cases faster, but slower than percpu_freelist
hlist+spinlock is the simplest free list with single spinlock.
As expeceted it has very bad scaling in SMP.
kmalloc is existing implementation which is still available via
BPF_F_NO_PREALLOC flag. It's significantly slower in single cpu and
in 8 cpu setup it's 3 times slower than pre-allocation with pcpu_freelist,
but saves memory, so in cases where map->max_entries can be large
and number of map update/delete per second is low, it may make
sense to use it.
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2016-03-08 13:57:15 +08:00
|
|
|
if (!prealloc)
|
|
|
|
htab_elem_set_ptr(l_new, key_size, pptr);
|
2019-02-01 07:40:04 +08:00
|
|
|
} else if (fd_htab_map_needs_adjust(htab)) {
|
|
|
|
size = round_up(size, 8);
|
2016-02-02 14:39:53 +08:00
|
|
|
memcpy(l_new->key + round_up(key_size, 8), value, size);
|
2019-02-01 07:40:04 +08:00
|
|
|
} else {
|
|
|
|
copy_map_value(&htab->map,
|
|
|
|
l_new->key + round_up(key_size, 8),
|
|
|
|
value);
|
2016-02-02 14:39:53 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
l_new->hash = hash;
|
|
|
|
return l_new;
|
2018-06-29 20:48:20 +08:00
|
|
|
dec_count:
|
|
|
|
atomic_dec(&htab->count);
|
|
|
|
return l_new;
|
2016-02-02 14:39:53 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
static int check_flags(struct bpf_htab *htab, struct htab_elem *l_old,
|
|
|
|
u64 map_flags)
|
|
|
|
{
|
2019-02-01 07:40:09 +08:00
|
|
|
if (l_old && (map_flags & ~BPF_F_LOCK) == BPF_NOEXIST)
|
2016-02-02 14:39:53 +08:00
|
|
|
/* elem already exists */
|
|
|
|
return -EEXIST;
|
|
|
|
|
2019-02-01 07:40:09 +08:00
|
|
|
if (!l_old && (map_flags & ~BPF_F_LOCK) == BPF_EXIST)
|
2016-02-02 14:39:53 +08:00
|
|
|
/* elem doesn't exist, cannot update it */
|
|
|
|
return -ENOENT;
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2014-11-14 09:36:45 +08:00
|
|
|
/* Called from syscall or from eBPF program */
|
|
|
|
static int htab_map_update_elem(struct bpf_map *map, void *key, void *value,
|
|
|
|
u64 map_flags)
|
|
|
|
{
|
|
|
|
struct bpf_htab *htab = container_of(map, struct bpf_htab, map);
|
2016-02-02 14:39:53 +08:00
|
|
|
struct htab_elem *l_new = NULL, *l_old;
|
2017-03-08 12:00:13 +08:00
|
|
|
struct hlist_nulls_head *head;
|
2014-11-14 09:36:45 +08:00
|
|
|
unsigned long flags;
|
2016-02-02 14:39:53 +08:00
|
|
|
struct bucket *b;
|
|
|
|
u32 key_size, hash;
|
2014-11-14 09:36:45 +08:00
|
|
|
int ret;
|
|
|
|
|
2019-02-01 07:40:09 +08:00
|
|
|
if (unlikely((map_flags & ~BPF_F_LOCK) > BPF_EXIST))
|
2014-11-14 09:36:45 +08:00
|
|
|
/* unknown flags */
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
WARN_ON_ONCE(!rcu_read_lock_held());
|
|
|
|
|
|
|
|
key_size = map->key_size;
|
|
|
|
|
2018-08-23 05:49:37 +08:00
|
|
|
hash = htab_map_hash(key, key_size, htab->hashrnd);
|
2016-02-02 14:39:53 +08:00
|
|
|
|
|
|
|
b = __select_bucket(htab, hash);
|
2015-12-29 22:40:27 +08:00
|
|
|
head = &b->head;
|
2014-11-14 09:36:45 +08:00
|
|
|
|
2019-02-01 07:40:09 +08:00
|
|
|
if (unlikely(map_flags & BPF_F_LOCK)) {
|
|
|
|
if (unlikely(!map_value_has_spin_lock(map)))
|
|
|
|
return -EINVAL;
|
|
|
|
/* find an element without taking the bucket lock */
|
|
|
|
l_old = lookup_nulls_elem_raw(head, hash, key, key_size,
|
|
|
|
htab->n_buckets);
|
|
|
|
ret = check_flags(htab, l_old, map_flags);
|
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
if (l_old) {
|
|
|
|
/* grab the element lock and update value in place */
|
|
|
|
copy_map_value_locked(map,
|
|
|
|
l_old->key + round_up(key_size, 8),
|
|
|
|
value, false);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
/* fall through, grab the bucket lock and lookup again.
|
|
|
|
* 99.9% chance that the element won't be found,
|
|
|
|
* but second lookup under lock has to be done.
|
|
|
|
*/
|
|
|
|
}
|
|
|
|
|
2020-02-24 22:01:50 +08:00
|
|
|
flags = htab_lock_bucket(htab, b);
|
2014-11-14 09:36:45 +08:00
|
|
|
|
2016-02-02 14:39:53 +08:00
|
|
|
l_old = lookup_elem_raw(head, hash, key, key_size);
|
2014-11-14 09:36:45 +08:00
|
|
|
|
2016-02-02 14:39:53 +08:00
|
|
|
ret = check_flags(htab, l_old, map_flags);
|
|
|
|
if (ret)
|
2014-11-14 09:36:45 +08:00
|
|
|
goto err;
|
|
|
|
|
2019-02-01 07:40:09 +08:00
|
|
|
if (unlikely(l_old && (map_flags & BPF_F_LOCK))) {
|
|
|
|
/* first lookup without the bucket lock didn't find the element,
|
|
|
|
* but second lookup with the bucket lock found it.
|
|
|
|
* This case is highly unlikely, but has to be dealt with:
|
|
|
|
* grab the element lock in addition to the bucket lock
|
|
|
|
* and update element in place
|
|
|
|
*/
|
|
|
|
copy_map_value_locked(map,
|
|
|
|
l_old->key + round_up(key_size, 8),
|
|
|
|
value, false);
|
|
|
|
ret = 0;
|
|
|
|
goto err;
|
|
|
|
}
|
|
|
|
|
2016-08-06 05:01:27 +08:00
|
|
|
l_new = alloc_htab_elem(htab, key, value, key_size, hash, false, false,
|
2017-03-22 10:05:04 +08:00
|
|
|
l_old);
|
bpf: pre-allocate hash map elements
If kprobe is placed on spin_unlock then calling kmalloc/kfree from
bpf programs is not safe, since the following dead lock is possible:
kfree->spin_lock(kmem_cache_node->lock)...spin_unlock->kprobe->
bpf_prog->map_update->kmalloc->spin_lock(of the same kmem_cache_node->lock)
and deadlocks.
The following solutions were considered and some implemented, but
eventually discarded
- kmem_cache_create for every map
- add recursion check to slow-path of slub
- use reserved memory in bpf_map_update for in_irq or in preempt_disabled
- kmalloc via irq_work
At the end pre-allocation of all map elements turned out to be the simplest
solution and since the user is charged upfront for all the memory, such
pre-allocation doesn't affect the user space visible behavior.
Since it's impossible to tell whether kprobe is triggered in a safe
location from kmalloc point of view, use pre-allocation by default
and introduce new BPF_F_NO_PREALLOC flag.
While testing of per-cpu hash maps it was discovered
that alloc_percpu(GFP_ATOMIC) has odd corner cases and often
fails to allocate memory even when 90% of it is free.
The pre-allocation of per-cpu hash elements solves this problem as well.
Turned out that bpf_map_update() quickly followed by
bpf_map_lookup()+bpf_map_delete() is very common pattern used
in many of iovisor/bcc/tools, so there is additional benefit of
pre-allocation, since such use cases are must faster.
Since all hash map elements are now pre-allocated we can remove
atomic increment of htab->count and save few more cycles.
Also add bpf_map_precharge_memlock() to check rlimit_memlock early to avoid
large malloc/free done by users who don't have sufficient limits.
Pre-allocation is done with vmalloc and alloc/free is done
via percpu_freelist. Here are performance numbers for different
pre-allocation algorithms that were implemented, but discarded
in favor of percpu_freelist:
1 cpu:
pcpu_ida 2.1M
pcpu_ida nolock 2.3M
bt 2.4M
kmalloc 1.8M
hlist+spinlock 2.3M
pcpu_freelist 2.6M
4 cpu:
pcpu_ida 1.5M
pcpu_ida nolock 1.8M
bt w/smp_align 1.7M
bt no/smp_align 1.1M
kmalloc 0.7M
hlist+spinlock 0.2M
pcpu_freelist 2.0M
8 cpu:
pcpu_ida 0.7M
bt w/smp_align 0.8M
kmalloc 0.4M
pcpu_freelist 1.5M
32 cpu:
kmalloc 0.13M
pcpu_freelist 0.49M
pcpu_ida nolock is a modified percpu_ida algorithm without
percpu_ida_cpu locks and without cross-cpu tag stealing.
It's faster than existing percpu_ida, but not as fast as pcpu_freelist.
bt is a variant of block/blk-mq-tag.c simlified and customized
for bpf use case. bt w/smp_align is using cache line for every 'long'
(similar to blk-mq-tag). bt no/smp_align allocates 'long'
bitmasks continuously to save memory. It's comparable to percpu_ida
and in some cases faster, but slower than percpu_freelist
hlist+spinlock is the simplest free list with single spinlock.
As expeceted it has very bad scaling in SMP.
kmalloc is existing implementation which is still available via
BPF_F_NO_PREALLOC flag. It's significantly slower in single cpu and
in 8 cpu setup it's 3 times slower than pre-allocation with pcpu_freelist,
but saves memory, so in cases where map->max_entries can be large
and number of map update/delete per second is low, it may make
sense to use it.
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2016-03-08 13:57:15 +08:00
|
|
|
if (IS_ERR(l_new)) {
|
|
|
|
/* all pre-allocated elements are in use or memory exhausted */
|
|
|
|
ret = PTR_ERR(l_new);
|
|
|
|
goto err;
|
|
|
|
}
|
|
|
|
|
2016-02-02 14:39:53 +08:00
|
|
|
/* add new element to the head of the list, so that
|
|
|
|
* concurrent search will find it before old elem
|
2014-11-14 09:36:45 +08:00
|
|
|
*/
|
2017-03-08 12:00:13 +08:00
|
|
|
hlist_nulls_add_head_rcu(&l_new->hash_node, head);
|
2014-11-14 09:36:45 +08:00
|
|
|
if (l_old) {
|
2017-03-08 12:00:13 +08:00
|
|
|
hlist_nulls_del_rcu(&l_old->hash_node);
|
2017-03-22 10:05:04 +08:00
|
|
|
if (!htab_is_prealloc(htab))
|
|
|
|
free_htab_elem(htab, l_old);
|
2014-11-14 09:36:45 +08:00
|
|
|
}
|
bpf: pre-allocate hash map elements
If kprobe is placed on spin_unlock then calling kmalloc/kfree from
bpf programs is not safe, since the following dead lock is possible:
kfree->spin_lock(kmem_cache_node->lock)...spin_unlock->kprobe->
bpf_prog->map_update->kmalloc->spin_lock(of the same kmem_cache_node->lock)
and deadlocks.
The following solutions were considered and some implemented, but
eventually discarded
- kmem_cache_create for every map
- add recursion check to slow-path of slub
- use reserved memory in bpf_map_update for in_irq or in preempt_disabled
- kmalloc via irq_work
At the end pre-allocation of all map elements turned out to be the simplest
solution and since the user is charged upfront for all the memory, such
pre-allocation doesn't affect the user space visible behavior.
Since it's impossible to tell whether kprobe is triggered in a safe
location from kmalloc point of view, use pre-allocation by default
and introduce new BPF_F_NO_PREALLOC flag.
While testing of per-cpu hash maps it was discovered
that alloc_percpu(GFP_ATOMIC) has odd corner cases and often
fails to allocate memory even when 90% of it is free.
The pre-allocation of per-cpu hash elements solves this problem as well.
Turned out that bpf_map_update() quickly followed by
bpf_map_lookup()+bpf_map_delete() is very common pattern used
in many of iovisor/bcc/tools, so there is additional benefit of
pre-allocation, since such use cases are must faster.
Since all hash map elements are now pre-allocated we can remove
atomic increment of htab->count and save few more cycles.
Also add bpf_map_precharge_memlock() to check rlimit_memlock early to avoid
large malloc/free done by users who don't have sufficient limits.
Pre-allocation is done with vmalloc and alloc/free is done
via percpu_freelist. Here are performance numbers for different
pre-allocation algorithms that were implemented, but discarded
in favor of percpu_freelist:
1 cpu:
pcpu_ida 2.1M
pcpu_ida nolock 2.3M
bt 2.4M
kmalloc 1.8M
hlist+spinlock 2.3M
pcpu_freelist 2.6M
4 cpu:
pcpu_ida 1.5M
pcpu_ida nolock 1.8M
bt w/smp_align 1.7M
bt no/smp_align 1.1M
kmalloc 0.7M
hlist+spinlock 0.2M
pcpu_freelist 2.0M
8 cpu:
pcpu_ida 0.7M
bt w/smp_align 0.8M
kmalloc 0.4M
pcpu_freelist 1.5M
32 cpu:
kmalloc 0.13M
pcpu_freelist 0.49M
pcpu_ida nolock is a modified percpu_ida algorithm without
percpu_ida_cpu locks and without cross-cpu tag stealing.
It's faster than existing percpu_ida, but not as fast as pcpu_freelist.
bt is a variant of block/blk-mq-tag.c simlified and customized
for bpf use case. bt w/smp_align is using cache line for every 'long'
(similar to blk-mq-tag). bt no/smp_align allocates 'long'
bitmasks continuously to save memory. It's comparable to percpu_ida
and in some cases faster, but slower than percpu_freelist
hlist+spinlock is the simplest free list with single spinlock.
As expeceted it has very bad scaling in SMP.
kmalloc is existing implementation which is still available via
BPF_F_NO_PREALLOC flag. It's significantly slower in single cpu and
in 8 cpu setup it's 3 times slower than pre-allocation with pcpu_freelist,
but saves memory, so in cases where map->max_entries can be large
and number of map update/delete per second is low, it may make
sense to use it.
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2016-03-08 13:57:15 +08:00
|
|
|
ret = 0;
|
2014-11-14 09:36:45 +08:00
|
|
|
err:
|
2020-02-24 22:01:50 +08:00
|
|
|
htab_unlock_bucket(htab, b, flags);
|
2014-11-14 09:36:45 +08:00
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2016-11-12 02:55:09 +08:00
|
|
|
static int htab_lru_map_update_elem(struct bpf_map *map, void *key, void *value,
|
|
|
|
u64 map_flags)
|
|
|
|
{
|
|
|
|
struct bpf_htab *htab = container_of(map, struct bpf_htab, map);
|
|
|
|
struct htab_elem *l_new, *l_old = NULL;
|
2017-03-08 12:00:13 +08:00
|
|
|
struct hlist_nulls_head *head;
|
2016-11-12 02:55:09 +08:00
|
|
|
unsigned long flags;
|
|
|
|
struct bucket *b;
|
|
|
|
u32 key_size, hash;
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
if (unlikely(map_flags > BPF_EXIST))
|
|
|
|
/* unknown flags */
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
WARN_ON_ONCE(!rcu_read_lock_held());
|
|
|
|
|
|
|
|
key_size = map->key_size;
|
|
|
|
|
2018-08-23 05:49:37 +08:00
|
|
|
hash = htab_map_hash(key, key_size, htab->hashrnd);
|
2016-11-12 02:55:09 +08:00
|
|
|
|
|
|
|
b = __select_bucket(htab, hash);
|
|
|
|
head = &b->head;
|
|
|
|
|
|
|
|
/* For LRU, we need to alloc before taking bucket's
|
|
|
|
* spinlock because getting free nodes from LRU may need
|
|
|
|
* to remove older elements from htab and this removal
|
|
|
|
* operation will need a bucket lock.
|
|
|
|
*/
|
|
|
|
l_new = prealloc_lru_pop(htab, key, hash);
|
|
|
|
if (!l_new)
|
|
|
|
return -ENOMEM;
|
|
|
|
memcpy(l_new->key + round_up(map->key_size, 8), value, map->value_size);
|
|
|
|
|
2020-02-24 22:01:50 +08:00
|
|
|
flags = htab_lock_bucket(htab, b);
|
2016-11-12 02:55:09 +08:00
|
|
|
|
|
|
|
l_old = lookup_elem_raw(head, hash, key, key_size);
|
|
|
|
|
|
|
|
ret = check_flags(htab, l_old, map_flags);
|
|
|
|
if (ret)
|
|
|
|
goto err;
|
|
|
|
|
|
|
|
/* add new element to the head of the list, so that
|
|
|
|
* concurrent search will find it before old elem
|
|
|
|
*/
|
2017-03-08 12:00:13 +08:00
|
|
|
hlist_nulls_add_head_rcu(&l_new->hash_node, head);
|
2016-11-12 02:55:09 +08:00
|
|
|
if (l_old) {
|
|
|
|
bpf_lru_node_set_ref(&l_new->lru_node);
|
2017-03-08 12:00:13 +08:00
|
|
|
hlist_nulls_del_rcu(&l_old->hash_node);
|
2016-11-12 02:55:09 +08:00
|
|
|
}
|
|
|
|
ret = 0;
|
|
|
|
|
|
|
|
err:
|
2020-02-24 22:01:50 +08:00
|
|
|
htab_unlock_bucket(htab, b, flags);
|
2016-11-12 02:55:09 +08:00
|
|
|
|
|
|
|
if (ret)
|
|
|
|
bpf_lru_push_free(&htab->lru, &l_new->lru_node);
|
|
|
|
else if (l_old)
|
|
|
|
bpf_lru_push_free(&htab->lru, &l_old->lru_node);
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
bpf: add lookup/update support for per-cpu hash and array maps
The functions bpf_map_lookup_elem(map, key, value) and
bpf_map_update_elem(map, key, value, flags) need to get/set
values from all-cpus for per-cpu hash and array maps,
so that user space can aggregate/update them as necessary.
Example of single counter aggregation in user space:
unsigned int nr_cpus = sysconf(_SC_NPROCESSORS_CONF);
long values[nr_cpus];
long value = 0;
bpf_lookup_elem(fd, key, values);
for (i = 0; i < nr_cpus; i++)
value += values[i];
The user space must provide round_up(value_size, 8) * nr_cpus
array to get/set values, since kernel will use 'long' copy
of per-cpu values to try to copy good counters atomically.
It's a best-effort, since bpf programs and user space are racing
to access the same memory.
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2016-02-02 14:39:55 +08:00
|
|
|
static int __htab_percpu_map_update_elem(struct bpf_map *map, void *key,
|
|
|
|
void *value, u64 map_flags,
|
|
|
|
bool onallcpus)
|
2016-02-02 14:39:53 +08:00
|
|
|
{
|
|
|
|
struct bpf_htab *htab = container_of(map, struct bpf_htab, map);
|
|
|
|
struct htab_elem *l_new = NULL, *l_old;
|
2017-03-08 12:00:13 +08:00
|
|
|
struct hlist_nulls_head *head;
|
2016-02-02 14:39:53 +08:00
|
|
|
unsigned long flags;
|
|
|
|
struct bucket *b;
|
|
|
|
u32 key_size, hash;
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
if (unlikely(map_flags > BPF_EXIST))
|
|
|
|
/* unknown flags */
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
WARN_ON_ONCE(!rcu_read_lock_held());
|
|
|
|
|
|
|
|
key_size = map->key_size;
|
|
|
|
|
2018-08-23 05:49:37 +08:00
|
|
|
hash = htab_map_hash(key, key_size, htab->hashrnd);
|
2016-02-02 14:39:53 +08:00
|
|
|
|
|
|
|
b = __select_bucket(htab, hash);
|
|
|
|
head = &b->head;
|
|
|
|
|
2020-02-24 22:01:50 +08:00
|
|
|
flags = htab_lock_bucket(htab, b);
|
2016-02-02 14:39:53 +08:00
|
|
|
|
|
|
|
l_old = lookup_elem_raw(head, hash, key, key_size);
|
|
|
|
|
|
|
|
ret = check_flags(htab, l_old, map_flags);
|
|
|
|
if (ret)
|
|
|
|
goto err;
|
|
|
|
|
|
|
|
if (l_old) {
|
|
|
|
/* per-cpu hash map can update value in-place */
|
2016-11-12 02:55:08 +08:00
|
|
|
pcpu_copy_value(htab, htab_elem_get_ptr(l_old, key_size),
|
|
|
|
value, onallcpus);
|
2016-02-02 14:39:53 +08:00
|
|
|
} else {
|
|
|
|
l_new = alloc_htab_elem(htab, key, value, key_size,
|
2017-03-22 10:05:04 +08:00
|
|
|
hash, true, onallcpus, NULL);
|
bpf: pre-allocate hash map elements
If kprobe is placed on spin_unlock then calling kmalloc/kfree from
bpf programs is not safe, since the following dead lock is possible:
kfree->spin_lock(kmem_cache_node->lock)...spin_unlock->kprobe->
bpf_prog->map_update->kmalloc->spin_lock(of the same kmem_cache_node->lock)
and deadlocks.
The following solutions were considered and some implemented, but
eventually discarded
- kmem_cache_create for every map
- add recursion check to slow-path of slub
- use reserved memory in bpf_map_update for in_irq or in preempt_disabled
- kmalloc via irq_work
At the end pre-allocation of all map elements turned out to be the simplest
solution and since the user is charged upfront for all the memory, such
pre-allocation doesn't affect the user space visible behavior.
Since it's impossible to tell whether kprobe is triggered in a safe
location from kmalloc point of view, use pre-allocation by default
and introduce new BPF_F_NO_PREALLOC flag.
While testing of per-cpu hash maps it was discovered
that alloc_percpu(GFP_ATOMIC) has odd corner cases and often
fails to allocate memory even when 90% of it is free.
The pre-allocation of per-cpu hash elements solves this problem as well.
Turned out that bpf_map_update() quickly followed by
bpf_map_lookup()+bpf_map_delete() is very common pattern used
in many of iovisor/bcc/tools, so there is additional benefit of
pre-allocation, since such use cases are must faster.
Since all hash map elements are now pre-allocated we can remove
atomic increment of htab->count and save few more cycles.
Also add bpf_map_precharge_memlock() to check rlimit_memlock early to avoid
large malloc/free done by users who don't have sufficient limits.
Pre-allocation is done with vmalloc and alloc/free is done
via percpu_freelist. Here are performance numbers for different
pre-allocation algorithms that were implemented, but discarded
in favor of percpu_freelist:
1 cpu:
pcpu_ida 2.1M
pcpu_ida nolock 2.3M
bt 2.4M
kmalloc 1.8M
hlist+spinlock 2.3M
pcpu_freelist 2.6M
4 cpu:
pcpu_ida 1.5M
pcpu_ida nolock 1.8M
bt w/smp_align 1.7M
bt no/smp_align 1.1M
kmalloc 0.7M
hlist+spinlock 0.2M
pcpu_freelist 2.0M
8 cpu:
pcpu_ida 0.7M
bt w/smp_align 0.8M
kmalloc 0.4M
pcpu_freelist 1.5M
32 cpu:
kmalloc 0.13M
pcpu_freelist 0.49M
pcpu_ida nolock is a modified percpu_ida algorithm without
percpu_ida_cpu locks and without cross-cpu tag stealing.
It's faster than existing percpu_ida, but not as fast as pcpu_freelist.
bt is a variant of block/blk-mq-tag.c simlified and customized
for bpf use case. bt w/smp_align is using cache line for every 'long'
(similar to blk-mq-tag). bt no/smp_align allocates 'long'
bitmasks continuously to save memory. It's comparable to percpu_ida
and in some cases faster, but slower than percpu_freelist
hlist+spinlock is the simplest free list with single spinlock.
As expeceted it has very bad scaling in SMP.
kmalloc is existing implementation which is still available via
BPF_F_NO_PREALLOC flag. It's significantly slower in single cpu and
in 8 cpu setup it's 3 times slower than pre-allocation with pcpu_freelist,
but saves memory, so in cases where map->max_entries can be large
and number of map update/delete per second is low, it may make
sense to use it.
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2016-03-08 13:57:15 +08:00
|
|
|
if (IS_ERR(l_new)) {
|
|
|
|
ret = PTR_ERR(l_new);
|
2016-02-02 14:39:53 +08:00
|
|
|
goto err;
|
|
|
|
}
|
2017-03-08 12:00:13 +08:00
|
|
|
hlist_nulls_add_head_rcu(&l_new->hash_node, head);
|
2016-02-02 14:39:53 +08:00
|
|
|
}
|
|
|
|
ret = 0;
|
|
|
|
err:
|
2020-02-24 22:01:50 +08:00
|
|
|
htab_unlock_bucket(htab, b, flags);
|
2016-02-02 14:39:53 +08:00
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2016-11-12 02:55:10 +08:00
|
|
|
static int __htab_lru_percpu_map_update_elem(struct bpf_map *map, void *key,
|
|
|
|
void *value, u64 map_flags,
|
|
|
|
bool onallcpus)
|
|
|
|
{
|
|
|
|
struct bpf_htab *htab = container_of(map, struct bpf_htab, map);
|
|
|
|
struct htab_elem *l_new = NULL, *l_old;
|
2017-03-08 12:00:13 +08:00
|
|
|
struct hlist_nulls_head *head;
|
2016-11-12 02:55:10 +08:00
|
|
|
unsigned long flags;
|
|
|
|
struct bucket *b;
|
|
|
|
u32 key_size, hash;
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
if (unlikely(map_flags > BPF_EXIST))
|
|
|
|
/* unknown flags */
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
WARN_ON_ONCE(!rcu_read_lock_held());
|
|
|
|
|
|
|
|
key_size = map->key_size;
|
|
|
|
|
2018-08-23 05:49:37 +08:00
|
|
|
hash = htab_map_hash(key, key_size, htab->hashrnd);
|
2016-11-12 02:55:10 +08:00
|
|
|
|
|
|
|
b = __select_bucket(htab, hash);
|
|
|
|
head = &b->head;
|
|
|
|
|
|
|
|
/* For LRU, we need to alloc before taking bucket's
|
|
|
|
* spinlock because LRU's elem alloc may need
|
|
|
|
* to remove older elem from htab and this removal
|
|
|
|
* operation will need a bucket lock.
|
|
|
|
*/
|
|
|
|
if (map_flags != BPF_EXIST) {
|
|
|
|
l_new = prealloc_lru_pop(htab, key, hash);
|
|
|
|
if (!l_new)
|
|
|
|
return -ENOMEM;
|
|
|
|
}
|
|
|
|
|
2020-02-24 22:01:50 +08:00
|
|
|
flags = htab_lock_bucket(htab, b);
|
2016-11-12 02:55:10 +08:00
|
|
|
|
|
|
|
l_old = lookup_elem_raw(head, hash, key, key_size);
|
|
|
|
|
|
|
|
ret = check_flags(htab, l_old, map_flags);
|
|
|
|
if (ret)
|
|
|
|
goto err;
|
|
|
|
|
|
|
|
if (l_old) {
|
|
|
|
bpf_lru_node_set_ref(&l_old->lru_node);
|
|
|
|
|
|
|
|
/* per-cpu hash map can update value in-place */
|
|
|
|
pcpu_copy_value(htab, htab_elem_get_ptr(l_old, key_size),
|
|
|
|
value, onallcpus);
|
|
|
|
} else {
|
|
|
|
pcpu_copy_value(htab, htab_elem_get_ptr(l_new, key_size),
|
|
|
|
value, onallcpus);
|
2017-03-08 12:00:13 +08:00
|
|
|
hlist_nulls_add_head_rcu(&l_new->hash_node, head);
|
2016-11-12 02:55:10 +08:00
|
|
|
l_new = NULL;
|
|
|
|
}
|
|
|
|
ret = 0;
|
|
|
|
err:
|
2020-02-24 22:01:50 +08:00
|
|
|
htab_unlock_bucket(htab, b, flags);
|
2016-11-12 02:55:10 +08:00
|
|
|
if (l_new)
|
|
|
|
bpf_lru_push_free(&htab->lru, &l_new->lru_node);
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
bpf: add lookup/update support for per-cpu hash and array maps
The functions bpf_map_lookup_elem(map, key, value) and
bpf_map_update_elem(map, key, value, flags) need to get/set
values from all-cpus for per-cpu hash and array maps,
so that user space can aggregate/update them as necessary.
Example of single counter aggregation in user space:
unsigned int nr_cpus = sysconf(_SC_NPROCESSORS_CONF);
long values[nr_cpus];
long value = 0;
bpf_lookup_elem(fd, key, values);
for (i = 0; i < nr_cpus; i++)
value += values[i];
The user space must provide round_up(value_size, 8) * nr_cpus
array to get/set values, since kernel will use 'long' copy
of per-cpu values to try to copy good counters atomically.
It's a best-effort, since bpf programs and user space are racing
to access the same memory.
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2016-02-02 14:39:55 +08:00
|
|
|
static int htab_percpu_map_update_elem(struct bpf_map *map, void *key,
|
|
|
|
void *value, u64 map_flags)
|
|
|
|
{
|
|
|
|
return __htab_percpu_map_update_elem(map, key, value, map_flags, false);
|
|
|
|
}
|
|
|
|
|
2016-11-12 02:55:10 +08:00
|
|
|
static int htab_lru_percpu_map_update_elem(struct bpf_map *map, void *key,
|
|
|
|
void *value, u64 map_flags)
|
|
|
|
{
|
|
|
|
return __htab_lru_percpu_map_update_elem(map, key, value, map_flags,
|
|
|
|
false);
|
|
|
|
}
|
|
|
|
|
2014-11-14 09:36:45 +08:00
|
|
|
/* Called from syscall or from eBPF program */
|
|
|
|
static int htab_map_delete_elem(struct bpf_map *map, void *key)
|
|
|
|
{
|
|
|
|
struct bpf_htab *htab = container_of(map, struct bpf_htab, map);
|
2017-03-08 12:00:13 +08:00
|
|
|
struct hlist_nulls_head *head;
|
2015-12-29 22:40:27 +08:00
|
|
|
struct bucket *b;
|
2014-11-14 09:36:45 +08:00
|
|
|
struct htab_elem *l;
|
|
|
|
unsigned long flags;
|
|
|
|
u32 hash, key_size;
|
|
|
|
int ret = -ENOENT;
|
|
|
|
|
|
|
|
WARN_ON_ONCE(!rcu_read_lock_held());
|
|
|
|
|
|
|
|
key_size = map->key_size;
|
|
|
|
|
2018-08-23 05:49:37 +08:00
|
|
|
hash = htab_map_hash(key, key_size, htab->hashrnd);
|
2015-12-29 22:40:27 +08:00
|
|
|
b = __select_bucket(htab, hash);
|
|
|
|
head = &b->head;
|
2014-11-14 09:36:45 +08:00
|
|
|
|
2020-02-24 22:01:50 +08:00
|
|
|
flags = htab_lock_bucket(htab, b);
|
2014-11-14 09:36:45 +08:00
|
|
|
|
|
|
|
l = lookup_elem_raw(head, hash, key, key_size);
|
|
|
|
|
|
|
|
if (l) {
|
2017-03-08 12:00:13 +08:00
|
|
|
hlist_nulls_del_rcu(&l->hash_node);
|
bpf: pre-allocate hash map elements
If kprobe is placed on spin_unlock then calling kmalloc/kfree from
bpf programs is not safe, since the following dead lock is possible:
kfree->spin_lock(kmem_cache_node->lock)...spin_unlock->kprobe->
bpf_prog->map_update->kmalloc->spin_lock(of the same kmem_cache_node->lock)
and deadlocks.
The following solutions were considered and some implemented, but
eventually discarded
- kmem_cache_create for every map
- add recursion check to slow-path of slub
- use reserved memory in bpf_map_update for in_irq or in preempt_disabled
- kmalloc via irq_work
At the end pre-allocation of all map elements turned out to be the simplest
solution and since the user is charged upfront for all the memory, such
pre-allocation doesn't affect the user space visible behavior.
Since it's impossible to tell whether kprobe is triggered in a safe
location from kmalloc point of view, use pre-allocation by default
and introduce new BPF_F_NO_PREALLOC flag.
While testing of per-cpu hash maps it was discovered
that alloc_percpu(GFP_ATOMIC) has odd corner cases and often
fails to allocate memory even when 90% of it is free.
The pre-allocation of per-cpu hash elements solves this problem as well.
Turned out that bpf_map_update() quickly followed by
bpf_map_lookup()+bpf_map_delete() is very common pattern used
in many of iovisor/bcc/tools, so there is additional benefit of
pre-allocation, since such use cases are must faster.
Since all hash map elements are now pre-allocated we can remove
atomic increment of htab->count and save few more cycles.
Also add bpf_map_precharge_memlock() to check rlimit_memlock early to avoid
large malloc/free done by users who don't have sufficient limits.
Pre-allocation is done with vmalloc and alloc/free is done
via percpu_freelist. Here are performance numbers for different
pre-allocation algorithms that were implemented, but discarded
in favor of percpu_freelist:
1 cpu:
pcpu_ida 2.1M
pcpu_ida nolock 2.3M
bt 2.4M
kmalloc 1.8M
hlist+spinlock 2.3M
pcpu_freelist 2.6M
4 cpu:
pcpu_ida 1.5M
pcpu_ida nolock 1.8M
bt w/smp_align 1.7M
bt no/smp_align 1.1M
kmalloc 0.7M
hlist+spinlock 0.2M
pcpu_freelist 2.0M
8 cpu:
pcpu_ida 0.7M
bt w/smp_align 0.8M
kmalloc 0.4M
pcpu_freelist 1.5M
32 cpu:
kmalloc 0.13M
pcpu_freelist 0.49M
pcpu_ida nolock is a modified percpu_ida algorithm without
percpu_ida_cpu locks and without cross-cpu tag stealing.
It's faster than existing percpu_ida, but not as fast as pcpu_freelist.
bt is a variant of block/blk-mq-tag.c simlified and customized
for bpf use case. bt w/smp_align is using cache line for every 'long'
(similar to blk-mq-tag). bt no/smp_align allocates 'long'
bitmasks continuously to save memory. It's comparable to percpu_ida
and in some cases faster, but slower than percpu_freelist
hlist+spinlock is the simplest free list with single spinlock.
As expeceted it has very bad scaling in SMP.
kmalloc is existing implementation which is still available via
BPF_F_NO_PREALLOC flag. It's significantly slower in single cpu and
in 8 cpu setup it's 3 times slower than pre-allocation with pcpu_freelist,
but saves memory, so in cases where map->max_entries can be large
and number of map update/delete per second is low, it may make
sense to use it.
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2016-03-08 13:57:15 +08:00
|
|
|
free_htab_elem(htab, l);
|
2014-11-14 09:36:45 +08:00
|
|
|
ret = 0;
|
|
|
|
}
|
|
|
|
|
2020-02-24 22:01:50 +08:00
|
|
|
htab_unlock_bucket(htab, b, flags);
|
2014-11-14 09:36:45 +08:00
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2016-11-12 02:55:09 +08:00
|
|
|
static int htab_lru_map_delete_elem(struct bpf_map *map, void *key)
|
|
|
|
{
|
|
|
|
struct bpf_htab *htab = container_of(map, struct bpf_htab, map);
|
2017-03-08 12:00:13 +08:00
|
|
|
struct hlist_nulls_head *head;
|
2016-11-12 02:55:09 +08:00
|
|
|
struct bucket *b;
|
|
|
|
struct htab_elem *l;
|
|
|
|
unsigned long flags;
|
|
|
|
u32 hash, key_size;
|
|
|
|
int ret = -ENOENT;
|
|
|
|
|
|
|
|
WARN_ON_ONCE(!rcu_read_lock_held());
|
|
|
|
|
|
|
|
key_size = map->key_size;
|
|
|
|
|
2018-08-23 05:49:37 +08:00
|
|
|
hash = htab_map_hash(key, key_size, htab->hashrnd);
|
2016-11-12 02:55:09 +08:00
|
|
|
b = __select_bucket(htab, hash);
|
|
|
|
head = &b->head;
|
|
|
|
|
2020-02-24 22:01:50 +08:00
|
|
|
flags = htab_lock_bucket(htab, b);
|
2016-11-12 02:55:09 +08:00
|
|
|
|
|
|
|
l = lookup_elem_raw(head, hash, key, key_size);
|
|
|
|
|
|
|
|
if (l) {
|
2017-03-08 12:00:13 +08:00
|
|
|
hlist_nulls_del_rcu(&l->hash_node);
|
2016-11-12 02:55:09 +08:00
|
|
|
ret = 0;
|
|
|
|
}
|
|
|
|
|
2020-02-24 22:01:50 +08:00
|
|
|
htab_unlock_bucket(htab, b, flags);
|
2016-11-12 02:55:09 +08:00
|
|
|
if (l)
|
|
|
|
bpf_lru_push_free(&htab->lru, &l->lru_node);
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2014-11-14 09:36:45 +08:00
|
|
|
static void delete_all_elements(struct bpf_htab *htab)
|
|
|
|
{
|
|
|
|
int i;
|
|
|
|
|
|
|
|
for (i = 0; i < htab->n_buckets; i++) {
|
2017-03-08 12:00:13 +08:00
|
|
|
struct hlist_nulls_head *head = select_bucket(htab, i);
|
|
|
|
struct hlist_nulls_node *n;
|
2014-11-14 09:36:45 +08:00
|
|
|
struct htab_elem *l;
|
|
|
|
|
2017-03-08 12:00:13 +08:00
|
|
|
hlist_nulls_for_each_entry_safe(l, n, head, hash_node) {
|
|
|
|
hlist_nulls_del_rcu(&l->hash_node);
|
2017-03-22 10:05:04 +08:00
|
|
|
htab_elem_free(htab, l);
|
2014-11-14 09:36:45 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
2017-03-23 01:00:34 +08:00
|
|
|
|
2014-11-14 09:36:45 +08:00
|
|
|
/* Called when map->refcnt goes to zero, either from workqueue or from syscall */
|
|
|
|
static void htab_map_free(struct bpf_map *map)
|
|
|
|
{
|
|
|
|
struct bpf_htab *htab = container_of(map, struct bpf_htab, map);
|
|
|
|
|
|
|
|
/* at this point bpf_prog->aux->refcnt == 0 and this map->refcnt == 0,
|
|
|
|
* so the programs (can be more than one that used this map) were
|
|
|
|
* disconnected from events. Wait for outstanding critical sections in
|
|
|
|
* these programs to complete
|
|
|
|
*/
|
|
|
|
synchronize_rcu();
|
|
|
|
|
bpf: pre-allocate hash map elements
If kprobe is placed on spin_unlock then calling kmalloc/kfree from
bpf programs is not safe, since the following dead lock is possible:
kfree->spin_lock(kmem_cache_node->lock)...spin_unlock->kprobe->
bpf_prog->map_update->kmalloc->spin_lock(of the same kmem_cache_node->lock)
and deadlocks.
The following solutions were considered and some implemented, but
eventually discarded
- kmem_cache_create for every map
- add recursion check to slow-path of slub
- use reserved memory in bpf_map_update for in_irq or in preempt_disabled
- kmalloc via irq_work
At the end pre-allocation of all map elements turned out to be the simplest
solution and since the user is charged upfront for all the memory, such
pre-allocation doesn't affect the user space visible behavior.
Since it's impossible to tell whether kprobe is triggered in a safe
location from kmalloc point of view, use pre-allocation by default
and introduce new BPF_F_NO_PREALLOC flag.
While testing of per-cpu hash maps it was discovered
that alloc_percpu(GFP_ATOMIC) has odd corner cases and often
fails to allocate memory even when 90% of it is free.
The pre-allocation of per-cpu hash elements solves this problem as well.
Turned out that bpf_map_update() quickly followed by
bpf_map_lookup()+bpf_map_delete() is very common pattern used
in many of iovisor/bcc/tools, so there is additional benefit of
pre-allocation, since such use cases are must faster.
Since all hash map elements are now pre-allocated we can remove
atomic increment of htab->count and save few more cycles.
Also add bpf_map_precharge_memlock() to check rlimit_memlock early to avoid
large malloc/free done by users who don't have sufficient limits.
Pre-allocation is done with vmalloc and alloc/free is done
via percpu_freelist. Here are performance numbers for different
pre-allocation algorithms that were implemented, but discarded
in favor of percpu_freelist:
1 cpu:
pcpu_ida 2.1M
pcpu_ida nolock 2.3M
bt 2.4M
kmalloc 1.8M
hlist+spinlock 2.3M
pcpu_freelist 2.6M
4 cpu:
pcpu_ida 1.5M
pcpu_ida nolock 1.8M
bt w/smp_align 1.7M
bt no/smp_align 1.1M
kmalloc 0.7M
hlist+spinlock 0.2M
pcpu_freelist 2.0M
8 cpu:
pcpu_ida 0.7M
bt w/smp_align 0.8M
kmalloc 0.4M
pcpu_freelist 1.5M
32 cpu:
kmalloc 0.13M
pcpu_freelist 0.49M
pcpu_ida nolock is a modified percpu_ida algorithm without
percpu_ida_cpu locks and without cross-cpu tag stealing.
It's faster than existing percpu_ida, but not as fast as pcpu_freelist.
bt is a variant of block/blk-mq-tag.c simlified and customized
for bpf use case. bt w/smp_align is using cache line for every 'long'
(similar to blk-mq-tag). bt no/smp_align allocates 'long'
bitmasks continuously to save memory. It's comparable to percpu_ida
and in some cases faster, but slower than percpu_freelist
hlist+spinlock is the simplest free list with single spinlock.
As expeceted it has very bad scaling in SMP.
kmalloc is existing implementation which is still available via
BPF_F_NO_PREALLOC flag. It's significantly slower in single cpu and
in 8 cpu setup it's 3 times slower than pre-allocation with pcpu_freelist,
but saves memory, so in cases where map->max_entries can be large
and number of map update/delete per second is low, it may make
sense to use it.
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2016-03-08 13:57:15 +08:00
|
|
|
/* some of free_htab_elem() callbacks for elements of this map may
|
|
|
|
* not have executed. Wait for them.
|
2014-11-14 09:36:45 +08:00
|
|
|
*/
|
bpf: pre-allocate hash map elements
If kprobe is placed on spin_unlock then calling kmalloc/kfree from
bpf programs is not safe, since the following dead lock is possible:
kfree->spin_lock(kmem_cache_node->lock)...spin_unlock->kprobe->
bpf_prog->map_update->kmalloc->spin_lock(of the same kmem_cache_node->lock)
and deadlocks.
The following solutions were considered and some implemented, but
eventually discarded
- kmem_cache_create for every map
- add recursion check to slow-path of slub
- use reserved memory in bpf_map_update for in_irq or in preempt_disabled
- kmalloc via irq_work
At the end pre-allocation of all map elements turned out to be the simplest
solution and since the user is charged upfront for all the memory, such
pre-allocation doesn't affect the user space visible behavior.
Since it's impossible to tell whether kprobe is triggered in a safe
location from kmalloc point of view, use pre-allocation by default
and introduce new BPF_F_NO_PREALLOC flag.
While testing of per-cpu hash maps it was discovered
that alloc_percpu(GFP_ATOMIC) has odd corner cases and often
fails to allocate memory even when 90% of it is free.
The pre-allocation of per-cpu hash elements solves this problem as well.
Turned out that bpf_map_update() quickly followed by
bpf_map_lookup()+bpf_map_delete() is very common pattern used
in many of iovisor/bcc/tools, so there is additional benefit of
pre-allocation, since such use cases are must faster.
Since all hash map elements are now pre-allocated we can remove
atomic increment of htab->count and save few more cycles.
Also add bpf_map_precharge_memlock() to check rlimit_memlock early to avoid
large malloc/free done by users who don't have sufficient limits.
Pre-allocation is done with vmalloc and alloc/free is done
via percpu_freelist. Here are performance numbers for different
pre-allocation algorithms that were implemented, but discarded
in favor of percpu_freelist:
1 cpu:
pcpu_ida 2.1M
pcpu_ida nolock 2.3M
bt 2.4M
kmalloc 1.8M
hlist+spinlock 2.3M
pcpu_freelist 2.6M
4 cpu:
pcpu_ida 1.5M
pcpu_ida nolock 1.8M
bt w/smp_align 1.7M
bt no/smp_align 1.1M
kmalloc 0.7M
hlist+spinlock 0.2M
pcpu_freelist 2.0M
8 cpu:
pcpu_ida 0.7M
bt w/smp_align 0.8M
kmalloc 0.4M
pcpu_freelist 1.5M
32 cpu:
kmalloc 0.13M
pcpu_freelist 0.49M
pcpu_ida nolock is a modified percpu_ida algorithm without
percpu_ida_cpu locks and without cross-cpu tag stealing.
It's faster than existing percpu_ida, but not as fast as pcpu_freelist.
bt is a variant of block/blk-mq-tag.c simlified and customized
for bpf use case. bt w/smp_align is using cache line for every 'long'
(similar to blk-mq-tag). bt no/smp_align allocates 'long'
bitmasks continuously to save memory. It's comparable to percpu_ida
and in some cases faster, but slower than percpu_freelist
hlist+spinlock is the simplest free list with single spinlock.
As expeceted it has very bad scaling in SMP.
kmalloc is existing implementation which is still available via
BPF_F_NO_PREALLOC flag. It's significantly slower in single cpu and
in 8 cpu setup it's 3 times slower than pre-allocation with pcpu_freelist,
but saves memory, so in cases where map->max_entries can be large
and number of map update/delete per second is low, it may make
sense to use it.
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2016-03-08 13:57:15 +08:00
|
|
|
rcu_barrier();
|
2017-03-22 10:05:04 +08:00
|
|
|
if (!htab_is_prealloc(htab))
|
bpf: pre-allocate hash map elements
If kprobe is placed on spin_unlock then calling kmalloc/kfree from
bpf programs is not safe, since the following dead lock is possible:
kfree->spin_lock(kmem_cache_node->lock)...spin_unlock->kprobe->
bpf_prog->map_update->kmalloc->spin_lock(of the same kmem_cache_node->lock)
and deadlocks.
The following solutions were considered and some implemented, but
eventually discarded
- kmem_cache_create for every map
- add recursion check to slow-path of slub
- use reserved memory in bpf_map_update for in_irq or in preempt_disabled
- kmalloc via irq_work
At the end pre-allocation of all map elements turned out to be the simplest
solution and since the user is charged upfront for all the memory, such
pre-allocation doesn't affect the user space visible behavior.
Since it's impossible to tell whether kprobe is triggered in a safe
location from kmalloc point of view, use pre-allocation by default
and introduce new BPF_F_NO_PREALLOC flag.
While testing of per-cpu hash maps it was discovered
that alloc_percpu(GFP_ATOMIC) has odd corner cases and often
fails to allocate memory even when 90% of it is free.
The pre-allocation of per-cpu hash elements solves this problem as well.
Turned out that bpf_map_update() quickly followed by
bpf_map_lookup()+bpf_map_delete() is very common pattern used
in many of iovisor/bcc/tools, so there is additional benefit of
pre-allocation, since such use cases are must faster.
Since all hash map elements are now pre-allocated we can remove
atomic increment of htab->count and save few more cycles.
Also add bpf_map_precharge_memlock() to check rlimit_memlock early to avoid
large malloc/free done by users who don't have sufficient limits.
Pre-allocation is done with vmalloc and alloc/free is done
via percpu_freelist. Here are performance numbers for different
pre-allocation algorithms that were implemented, but discarded
in favor of percpu_freelist:
1 cpu:
pcpu_ida 2.1M
pcpu_ida nolock 2.3M
bt 2.4M
kmalloc 1.8M
hlist+spinlock 2.3M
pcpu_freelist 2.6M
4 cpu:
pcpu_ida 1.5M
pcpu_ida nolock 1.8M
bt w/smp_align 1.7M
bt no/smp_align 1.1M
kmalloc 0.7M
hlist+spinlock 0.2M
pcpu_freelist 2.0M
8 cpu:
pcpu_ida 0.7M
bt w/smp_align 0.8M
kmalloc 0.4M
pcpu_freelist 1.5M
32 cpu:
kmalloc 0.13M
pcpu_freelist 0.49M
pcpu_ida nolock is a modified percpu_ida algorithm without
percpu_ida_cpu locks and without cross-cpu tag stealing.
It's faster than existing percpu_ida, but not as fast as pcpu_freelist.
bt is a variant of block/blk-mq-tag.c simlified and customized
for bpf use case. bt w/smp_align is using cache line for every 'long'
(similar to blk-mq-tag). bt no/smp_align allocates 'long'
bitmasks continuously to save memory. It's comparable to percpu_ida
and in some cases faster, but slower than percpu_freelist
hlist+spinlock is the simplest free list with single spinlock.
As expeceted it has very bad scaling in SMP.
kmalloc is existing implementation which is still available via
BPF_F_NO_PREALLOC flag. It's significantly slower in single cpu and
in 8 cpu setup it's 3 times slower than pre-allocation with pcpu_freelist,
but saves memory, so in cases where map->max_entries can be large
and number of map update/delete per second is low, it may make
sense to use it.
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2016-03-08 13:57:15 +08:00
|
|
|
delete_all_elements(htab);
|
2016-11-12 02:55:09 +08:00
|
|
|
else
|
|
|
|
prealloc_destroy(htab);
|
|
|
|
|
2016-08-06 05:01:27 +08:00
|
|
|
free_percpu(htab->extra_elems);
|
bpf: don't trigger OOM killer under pressure with map alloc
This patch adds two helpers, bpf_map_area_alloc() and bpf_map_area_free(),
that are to be used for map allocations. Using kmalloc() for very large
allocations can cause excessive work within the page allocator, so i) fall
back earlier to vmalloc() when the attempt is considered costly anyway,
and even more importantly ii) don't trigger OOM killer with any of the
allocators.
Since this is based on a user space request, for example, when creating
maps with element pre-allocation, we really want such requests to fail
instead of killing other user space processes.
Also, don't spam the kernel log with warnings should any of the allocations
fail under pressure. Given that, we can make backend selection in
bpf_map_area_alloc() generic, and convert all maps over to use this API
for spots with potentially large allocation requests.
Note, replacing the one kmalloc_array() is fine as overflow checks happen
earlier in htab_map_alloc(), since it must also protect the multiplication
for vmalloc() should kmalloc_array() fail.
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-01-18 22:14:17 +08:00
|
|
|
bpf_map_area_free(htab->buckets);
|
2014-11-14 09:36:45 +08:00
|
|
|
kfree(htab);
|
|
|
|
}
|
|
|
|
|
2018-08-09 23:55:20 +08:00
|
|
|
static void htab_map_seq_show_elem(struct bpf_map *map, void *key,
|
|
|
|
struct seq_file *m)
|
|
|
|
{
|
|
|
|
void *value;
|
|
|
|
|
|
|
|
rcu_read_lock();
|
|
|
|
|
|
|
|
value = htab_map_lookup_elem(map, key);
|
|
|
|
if (!value) {
|
|
|
|
rcu_read_unlock();
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
btf_type_seq_show(map->btf, map->btf_key_type_id, key, m);
|
|
|
|
seq_puts(m, ": ");
|
|
|
|
btf_type_seq_show(map->btf, map->btf_value_type_id, value, m);
|
|
|
|
seq_puts(m, "\n");
|
|
|
|
|
|
|
|
rcu_read_unlock();
|
|
|
|
}
|
|
|
|
|
2020-01-16 02:43:04 +08:00
|
|
|
static int
|
|
|
|
__htab_map_lookup_and_delete_batch(struct bpf_map *map,
|
|
|
|
const union bpf_attr *attr,
|
|
|
|
union bpf_attr __user *uattr,
|
|
|
|
bool do_delete, bool is_lru_map,
|
|
|
|
bool is_percpu)
|
|
|
|
{
|
|
|
|
struct bpf_htab *htab = container_of(map, struct bpf_htab, map);
|
|
|
|
u32 bucket_cnt, total, key_size, value_size, roundup_key_size;
|
|
|
|
void *keys = NULL, *values = NULL, *value, *dst_key, *dst_val;
|
|
|
|
void __user *uvalues = u64_to_user_ptr(attr->batch.values);
|
|
|
|
void __user *ukeys = u64_to_user_ptr(attr->batch.keys);
|
|
|
|
void *ubatch = u64_to_user_ptr(attr->batch.in_batch);
|
|
|
|
u32 batch, max_count, size, bucket_size;
|
2020-02-20 07:47:57 +08:00
|
|
|
struct htab_elem *node_to_free = NULL;
|
2020-01-16 02:43:04 +08:00
|
|
|
u64 elem_map_flags, map_flags;
|
|
|
|
struct hlist_nulls_head *head;
|
|
|
|
struct hlist_nulls_node *n;
|
2020-02-19 01:25:52 +08:00
|
|
|
unsigned long flags = 0;
|
|
|
|
bool locked = false;
|
2020-01-16 02:43:04 +08:00
|
|
|
struct htab_elem *l;
|
|
|
|
struct bucket *b;
|
|
|
|
int ret = 0;
|
|
|
|
|
|
|
|
elem_map_flags = attr->batch.elem_flags;
|
|
|
|
if ((elem_map_flags & ~BPF_F_LOCK) ||
|
|
|
|
((elem_map_flags & BPF_F_LOCK) && !map_value_has_spin_lock(map)))
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
map_flags = attr->batch.flags;
|
|
|
|
if (map_flags)
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
max_count = attr->batch.count;
|
|
|
|
if (!max_count)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
if (put_user(0, &uattr->batch.count))
|
|
|
|
return -EFAULT;
|
|
|
|
|
|
|
|
batch = 0;
|
|
|
|
if (ubatch && copy_from_user(&batch, ubatch, sizeof(batch)))
|
|
|
|
return -EFAULT;
|
|
|
|
|
|
|
|
if (batch >= htab->n_buckets)
|
|
|
|
return -ENOENT;
|
|
|
|
|
|
|
|
key_size = htab->map.key_size;
|
|
|
|
roundup_key_size = round_up(htab->map.key_size, 8);
|
|
|
|
value_size = htab->map.value_size;
|
|
|
|
size = round_up(value_size, 8);
|
|
|
|
if (is_percpu)
|
|
|
|
value_size = size * num_possible_cpus();
|
|
|
|
total = 0;
|
|
|
|
/* while experimenting with hash tables with sizes ranging from 10 to
|
|
|
|
* 1000, it was observed that a bucket can have upto 5 entries.
|
|
|
|
*/
|
|
|
|
bucket_size = 5;
|
|
|
|
|
|
|
|
alloc:
|
|
|
|
/* We cannot do copy_from_user or copy_to_user inside
|
|
|
|
* the rcu_read_lock. Allocate enough space here.
|
|
|
|
*/
|
|
|
|
keys = kvmalloc(key_size * bucket_size, GFP_USER | __GFP_NOWARN);
|
|
|
|
values = kvmalloc(value_size * bucket_size, GFP_USER | __GFP_NOWARN);
|
|
|
|
if (!keys || !values) {
|
|
|
|
ret = -ENOMEM;
|
|
|
|
goto after_loop;
|
|
|
|
}
|
|
|
|
|
|
|
|
again:
|
2020-02-24 22:01:48 +08:00
|
|
|
bpf_disable_instrumentation();
|
2020-01-16 02:43:04 +08:00
|
|
|
rcu_read_lock();
|
|
|
|
again_nocopy:
|
|
|
|
dst_key = keys;
|
|
|
|
dst_val = values;
|
|
|
|
b = &htab->buckets[batch];
|
|
|
|
head = &b->head;
|
2020-02-19 01:25:52 +08:00
|
|
|
/* do not grab the lock unless need it (bucket_cnt > 0). */
|
|
|
|
if (locked)
|
2020-02-24 22:01:50 +08:00
|
|
|
flags = htab_lock_bucket(htab, b);
|
2020-01-16 02:43:04 +08:00
|
|
|
|
|
|
|
bucket_cnt = 0;
|
|
|
|
hlist_nulls_for_each_entry_rcu(l, n, head, hash_node)
|
|
|
|
bucket_cnt++;
|
|
|
|
|
2020-02-19 01:25:52 +08:00
|
|
|
if (bucket_cnt && !locked) {
|
|
|
|
locked = true;
|
|
|
|
goto again_nocopy;
|
|
|
|
}
|
|
|
|
|
2020-01-16 02:43:04 +08:00
|
|
|
if (bucket_cnt > (max_count - total)) {
|
|
|
|
if (total == 0)
|
|
|
|
ret = -ENOSPC;
|
2020-02-19 01:25:52 +08:00
|
|
|
/* Note that since bucket_cnt > 0 here, it is implicit
|
|
|
|
* that the locked was grabbed, so release it.
|
|
|
|
*/
|
2020-02-24 22:01:50 +08:00
|
|
|
htab_unlock_bucket(htab, b, flags);
|
2020-01-16 02:43:04 +08:00
|
|
|
rcu_read_unlock();
|
2020-02-24 22:01:48 +08:00
|
|
|
bpf_enable_instrumentation();
|
2020-01-16 02:43:04 +08:00
|
|
|
goto after_loop;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (bucket_cnt > bucket_size) {
|
|
|
|
bucket_size = bucket_cnt;
|
2020-02-19 01:25:52 +08:00
|
|
|
/* Note that since bucket_cnt > 0 here, it is implicit
|
|
|
|
* that the locked was grabbed, so release it.
|
|
|
|
*/
|
2020-02-24 22:01:50 +08:00
|
|
|
htab_unlock_bucket(htab, b, flags);
|
2020-01-16 02:43:04 +08:00
|
|
|
rcu_read_unlock();
|
2020-02-24 22:01:48 +08:00
|
|
|
bpf_enable_instrumentation();
|
2020-01-16 02:43:04 +08:00
|
|
|
kvfree(keys);
|
|
|
|
kvfree(values);
|
|
|
|
goto alloc;
|
|
|
|
}
|
|
|
|
|
2020-02-19 01:25:52 +08:00
|
|
|
/* Next block is only safe to run if you have grabbed the lock */
|
|
|
|
if (!locked)
|
|
|
|
goto next_batch;
|
|
|
|
|
2020-01-16 02:43:04 +08:00
|
|
|
hlist_nulls_for_each_entry_safe(l, n, head, hash_node) {
|
|
|
|
memcpy(dst_key, l->key, key_size);
|
|
|
|
|
|
|
|
if (is_percpu) {
|
|
|
|
int off = 0, cpu;
|
|
|
|
void __percpu *pptr;
|
|
|
|
|
|
|
|
pptr = htab_elem_get_ptr(l, map->key_size);
|
|
|
|
for_each_possible_cpu(cpu) {
|
|
|
|
bpf_long_memcpy(dst_val + off,
|
|
|
|
per_cpu_ptr(pptr, cpu), size);
|
|
|
|
off += size;
|
|
|
|
}
|
|
|
|
} else {
|
|
|
|
value = l->key + roundup_key_size;
|
|
|
|
if (elem_map_flags & BPF_F_LOCK)
|
|
|
|
copy_map_value_locked(map, dst_val, value,
|
|
|
|
true);
|
|
|
|
else
|
|
|
|
copy_map_value(map, dst_val, value);
|
|
|
|
check_and_init_map_lock(map, dst_val);
|
|
|
|
}
|
|
|
|
if (do_delete) {
|
|
|
|
hlist_nulls_del_rcu(&l->hash_node);
|
2020-02-20 07:47:57 +08:00
|
|
|
|
|
|
|
/* bpf_lru_push_free() will acquire lru_lock, which
|
|
|
|
* may cause deadlock. See comments in function
|
|
|
|
* prealloc_lru_pop(). Let us do bpf_lru_push_free()
|
|
|
|
* after releasing the bucket lock.
|
|
|
|
*/
|
|
|
|
if (is_lru_map) {
|
|
|
|
l->batch_flink = node_to_free;
|
|
|
|
node_to_free = l;
|
|
|
|
} else {
|
2020-01-16 02:43:04 +08:00
|
|
|
free_htab_elem(htab, l);
|
2020-02-20 07:47:57 +08:00
|
|
|
}
|
2020-01-16 02:43:04 +08:00
|
|
|
}
|
|
|
|
dst_key += key_size;
|
|
|
|
dst_val += value_size;
|
|
|
|
}
|
|
|
|
|
2020-02-24 22:01:50 +08:00
|
|
|
htab_unlock_bucket(htab, b, flags);
|
2020-02-19 01:25:52 +08:00
|
|
|
locked = false;
|
2020-02-20 07:47:57 +08:00
|
|
|
|
|
|
|
while (node_to_free) {
|
|
|
|
l = node_to_free;
|
|
|
|
node_to_free = node_to_free->batch_flink;
|
|
|
|
bpf_lru_push_free(&htab->lru, &l->lru_node);
|
|
|
|
}
|
|
|
|
|
2020-02-19 01:25:52 +08:00
|
|
|
next_batch:
|
2020-01-16 02:43:04 +08:00
|
|
|
/* If we are not copying data, we can go to next bucket and avoid
|
|
|
|
* unlocking the rcu.
|
|
|
|
*/
|
|
|
|
if (!bucket_cnt && (batch + 1 < htab->n_buckets)) {
|
|
|
|
batch++;
|
|
|
|
goto again_nocopy;
|
|
|
|
}
|
|
|
|
|
|
|
|
rcu_read_unlock();
|
2020-02-24 22:01:48 +08:00
|
|
|
bpf_enable_instrumentation();
|
2020-01-16 02:43:04 +08:00
|
|
|
if (bucket_cnt && (copy_to_user(ukeys + total * key_size, keys,
|
|
|
|
key_size * bucket_cnt) ||
|
|
|
|
copy_to_user(uvalues + total * value_size, values,
|
|
|
|
value_size * bucket_cnt))) {
|
|
|
|
ret = -EFAULT;
|
|
|
|
goto after_loop;
|
|
|
|
}
|
|
|
|
|
|
|
|
total += bucket_cnt;
|
|
|
|
batch++;
|
|
|
|
if (batch >= htab->n_buckets) {
|
|
|
|
ret = -ENOENT;
|
|
|
|
goto after_loop;
|
|
|
|
}
|
|
|
|
goto again;
|
|
|
|
|
|
|
|
after_loop:
|
|
|
|
if (ret == -EFAULT)
|
|
|
|
goto out;
|
|
|
|
|
|
|
|
/* copy # of entries and next batch */
|
|
|
|
ubatch = u64_to_user_ptr(attr->batch.out_batch);
|
|
|
|
if (copy_to_user(ubatch, &batch, sizeof(batch)) ||
|
|
|
|
put_user(total, &uattr->batch.count))
|
|
|
|
ret = -EFAULT;
|
|
|
|
|
|
|
|
out:
|
|
|
|
kvfree(keys);
|
|
|
|
kvfree(values);
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int
|
|
|
|
htab_percpu_map_lookup_batch(struct bpf_map *map, const union bpf_attr *attr,
|
|
|
|
union bpf_attr __user *uattr)
|
|
|
|
{
|
|
|
|
return __htab_map_lookup_and_delete_batch(map, attr, uattr, false,
|
|
|
|
false, true);
|
|
|
|
}
|
|
|
|
|
|
|
|
static int
|
|
|
|
htab_percpu_map_lookup_and_delete_batch(struct bpf_map *map,
|
|
|
|
const union bpf_attr *attr,
|
|
|
|
union bpf_attr __user *uattr)
|
|
|
|
{
|
|
|
|
return __htab_map_lookup_and_delete_batch(map, attr, uattr, true,
|
|
|
|
false, true);
|
|
|
|
}
|
|
|
|
|
|
|
|
static int
|
|
|
|
htab_map_lookup_batch(struct bpf_map *map, const union bpf_attr *attr,
|
|
|
|
union bpf_attr __user *uattr)
|
|
|
|
{
|
|
|
|
return __htab_map_lookup_and_delete_batch(map, attr, uattr, false,
|
|
|
|
false, false);
|
|
|
|
}
|
|
|
|
|
|
|
|
static int
|
|
|
|
htab_map_lookup_and_delete_batch(struct bpf_map *map,
|
|
|
|
const union bpf_attr *attr,
|
|
|
|
union bpf_attr __user *uattr)
|
|
|
|
{
|
|
|
|
return __htab_map_lookup_and_delete_batch(map, attr, uattr, true,
|
|
|
|
false, false);
|
|
|
|
}
|
|
|
|
|
|
|
|
static int
|
|
|
|
htab_lru_percpu_map_lookup_batch(struct bpf_map *map,
|
|
|
|
const union bpf_attr *attr,
|
|
|
|
union bpf_attr __user *uattr)
|
|
|
|
{
|
|
|
|
return __htab_map_lookup_and_delete_batch(map, attr, uattr, false,
|
|
|
|
true, true);
|
|
|
|
}
|
|
|
|
|
|
|
|
static int
|
|
|
|
htab_lru_percpu_map_lookup_and_delete_batch(struct bpf_map *map,
|
|
|
|
const union bpf_attr *attr,
|
|
|
|
union bpf_attr __user *uattr)
|
|
|
|
{
|
|
|
|
return __htab_map_lookup_and_delete_batch(map, attr, uattr, true,
|
|
|
|
true, true);
|
|
|
|
}
|
|
|
|
|
|
|
|
static int
|
|
|
|
htab_lru_map_lookup_batch(struct bpf_map *map, const union bpf_attr *attr,
|
|
|
|
union bpf_attr __user *uattr)
|
|
|
|
{
|
|
|
|
return __htab_map_lookup_and_delete_batch(map, attr, uattr, false,
|
|
|
|
true, false);
|
|
|
|
}
|
|
|
|
|
|
|
|
static int
|
|
|
|
htab_lru_map_lookup_and_delete_batch(struct bpf_map *map,
|
|
|
|
const union bpf_attr *attr,
|
|
|
|
union bpf_attr __user *uattr)
|
|
|
|
{
|
|
|
|
return __htab_map_lookup_and_delete_batch(map, attr, uattr, true,
|
|
|
|
true, false);
|
|
|
|
}
|
|
|
|
|
2017-04-11 21:34:58 +08:00
|
|
|
const struct bpf_map_ops htab_map_ops = {
|
2018-01-12 12:29:05 +08:00
|
|
|
.map_alloc_check = htab_map_alloc_check,
|
2014-11-14 09:36:45 +08:00
|
|
|
.map_alloc = htab_map_alloc,
|
|
|
|
.map_free = htab_map_free,
|
|
|
|
.map_get_next_key = htab_map_get_next_key,
|
|
|
|
.map_lookup_elem = htab_map_lookup_elem,
|
|
|
|
.map_update_elem = htab_map_update_elem,
|
|
|
|
.map_delete_elem = htab_map_delete_elem,
|
2017-03-16 09:26:43 +08:00
|
|
|
.map_gen_lookup = htab_map_gen_lookup,
|
2018-08-09 23:55:20 +08:00
|
|
|
.map_seq_show_elem = htab_map_seq_show_elem,
|
2020-01-16 02:43:04 +08:00
|
|
|
BATCH_OPS(htab),
|
2014-11-14 09:36:45 +08:00
|
|
|
};
|
|
|
|
|
2017-04-11 21:34:58 +08:00
|
|
|
const struct bpf_map_ops htab_lru_map_ops = {
|
2018-01-12 12:29:05 +08:00
|
|
|
.map_alloc_check = htab_map_alloc_check,
|
2016-11-12 02:55:09 +08:00
|
|
|
.map_alloc = htab_map_alloc,
|
|
|
|
.map_free = htab_map_free,
|
|
|
|
.map_get_next_key = htab_map_get_next_key,
|
|
|
|
.map_lookup_elem = htab_lru_map_lookup_elem,
|
2019-05-14 07:18:56 +08:00
|
|
|
.map_lookup_elem_sys_only = htab_lru_map_lookup_elem_sys,
|
2016-11-12 02:55:09 +08:00
|
|
|
.map_update_elem = htab_lru_map_update_elem,
|
|
|
|
.map_delete_elem = htab_lru_map_delete_elem,
|
2017-09-01 14:27:12 +08:00
|
|
|
.map_gen_lookup = htab_lru_map_gen_lookup,
|
2018-08-09 23:55:20 +08:00
|
|
|
.map_seq_show_elem = htab_map_seq_show_elem,
|
2020-01-16 02:43:04 +08:00
|
|
|
BATCH_OPS(htab_lru),
|
2016-11-12 02:55:09 +08:00
|
|
|
};
|
|
|
|
|
2016-02-02 14:39:53 +08:00
|
|
|
/* Called from eBPF program */
|
|
|
|
static void *htab_percpu_map_lookup_elem(struct bpf_map *map, void *key)
|
|
|
|
{
|
|
|
|
struct htab_elem *l = __htab_map_lookup_elem(map, key);
|
|
|
|
|
|
|
|
if (l)
|
|
|
|
return this_cpu_ptr(htab_elem_get_ptr(l, map->key_size));
|
|
|
|
else
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
2016-11-12 02:55:10 +08:00
|
|
|
static void *htab_lru_percpu_map_lookup_elem(struct bpf_map *map, void *key)
|
|
|
|
{
|
|
|
|
struct htab_elem *l = __htab_map_lookup_elem(map, key);
|
|
|
|
|
|
|
|
if (l) {
|
|
|
|
bpf_lru_node_set_ref(&l->lru_node);
|
|
|
|
return this_cpu_ptr(htab_elem_get_ptr(l, map->key_size));
|
|
|
|
}
|
|
|
|
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
bpf: add lookup/update support for per-cpu hash and array maps
The functions bpf_map_lookup_elem(map, key, value) and
bpf_map_update_elem(map, key, value, flags) need to get/set
values from all-cpus for per-cpu hash and array maps,
so that user space can aggregate/update them as necessary.
Example of single counter aggregation in user space:
unsigned int nr_cpus = sysconf(_SC_NPROCESSORS_CONF);
long values[nr_cpus];
long value = 0;
bpf_lookup_elem(fd, key, values);
for (i = 0; i < nr_cpus; i++)
value += values[i];
The user space must provide round_up(value_size, 8) * nr_cpus
array to get/set values, since kernel will use 'long' copy
of per-cpu values to try to copy good counters atomically.
It's a best-effort, since bpf programs and user space are racing
to access the same memory.
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2016-02-02 14:39:55 +08:00
|
|
|
int bpf_percpu_hash_copy(struct bpf_map *map, void *key, void *value)
|
|
|
|
{
|
|
|
|
struct htab_elem *l;
|
|
|
|
void __percpu *pptr;
|
|
|
|
int ret = -ENOENT;
|
|
|
|
int cpu, off = 0;
|
|
|
|
u32 size;
|
|
|
|
|
|
|
|
/* per_cpu areas are zero-filled and bpf programs can only
|
|
|
|
* access 'value_size' of them, so copying rounded areas
|
|
|
|
* will not leak any kernel data
|
|
|
|
*/
|
|
|
|
size = round_up(map->value_size, 8);
|
|
|
|
rcu_read_lock();
|
|
|
|
l = __htab_map_lookup_elem(map, key);
|
|
|
|
if (!l)
|
|
|
|
goto out;
|
2019-05-14 07:18:56 +08:00
|
|
|
/* We do not mark LRU map element here in order to not mess up
|
|
|
|
* eviction heuristics when user space does a map walk.
|
|
|
|
*/
|
bpf: add lookup/update support for per-cpu hash and array maps
The functions bpf_map_lookup_elem(map, key, value) and
bpf_map_update_elem(map, key, value, flags) need to get/set
values from all-cpus for per-cpu hash and array maps,
so that user space can aggregate/update them as necessary.
Example of single counter aggregation in user space:
unsigned int nr_cpus = sysconf(_SC_NPROCESSORS_CONF);
long values[nr_cpus];
long value = 0;
bpf_lookup_elem(fd, key, values);
for (i = 0; i < nr_cpus; i++)
value += values[i];
The user space must provide round_up(value_size, 8) * nr_cpus
array to get/set values, since kernel will use 'long' copy
of per-cpu values to try to copy good counters atomically.
It's a best-effort, since bpf programs and user space are racing
to access the same memory.
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2016-02-02 14:39:55 +08:00
|
|
|
pptr = htab_elem_get_ptr(l, map->key_size);
|
|
|
|
for_each_possible_cpu(cpu) {
|
|
|
|
bpf_long_memcpy(value + off,
|
|
|
|
per_cpu_ptr(pptr, cpu), size);
|
|
|
|
off += size;
|
|
|
|
}
|
|
|
|
ret = 0;
|
|
|
|
out:
|
|
|
|
rcu_read_unlock();
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
int bpf_percpu_hash_update(struct bpf_map *map, void *key, void *value,
|
|
|
|
u64 map_flags)
|
|
|
|
{
|
2016-11-12 02:55:10 +08:00
|
|
|
struct bpf_htab *htab = container_of(map, struct bpf_htab, map);
|
2016-02-20 02:53:10 +08:00
|
|
|
int ret;
|
|
|
|
|
|
|
|
rcu_read_lock();
|
2016-11-12 02:55:10 +08:00
|
|
|
if (htab_is_lru(htab))
|
|
|
|
ret = __htab_lru_percpu_map_update_elem(map, key, value,
|
|
|
|
map_flags, true);
|
|
|
|
else
|
|
|
|
ret = __htab_percpu_map_update_elem(map, key, value, map_flags,
|
|
|
|
true);
|
2016-02-20 02:53:10 +08:00
|
|
|
rcu_read_unlock();
|
|
|
|
|
|
|
|
return ret;
|
bpf: add lookup/update support for per-cpu hash and array maps
The functions bpf_map_lookup_elem(map, key, value) and
bpf_map_update_elem(map, key, value, flags) need to get/set
values from all-cpus for per-cpu hash and array maps,
so that user space can aggregate/update them as necessary.
Example of single counter aggregation in user space:
unsigned int nr_cpus = sysconf(_SC_NPROCESSORS_CONF);
long values[nr_cpus];
long value = 0;
bpf_lookup_elem(fd, key, values);
for (i = 0; i < nr_cpus; i++)
value += values[i];
The user space must provide round_up(value_size, 8) * nr_cpus
array to get/set values, since kernel will use 'long' copy
of per-cpu values to try to copy good counters atomically.
It's a best-effort, since bpf programs and user space are racing
to access the same memory.
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2016-02-02 14:39:55 +08:00
|
|
|
}
|
|
|
|
|
bpf: add bpffs pretty print for percpu arraymap/hash/lru_hash
Added bpffs pretty print for percpu arraymap, percpu hashmap
and percpu lru hashmap.
For each map <key, value> pair, the format is:
<key_value>: {
cpu0: <value_on_cpu0>
cpu1: <value_on_cpu1>
...
cpun: <value_on_cpun>
}
For example, on my VM, there are 4 cpus, and
for test_btf test in the next patch:
cat /sys/fs/bpf/pprint_test_percpu_hash
You may get:
...
43602: {
cpu0: {43602,0,-43602,0x3,0xaa52,0x3,{43602|[82,170,0,0,0,0,0,0]},ENUM_TWO}
cpu1: {43602,0,-43602,0x3,0xaa52,0x3,{43602|[82,170,0,0,0,0,0,0]},ENUM_TWO}
cpu2: {43602,0,-43602,0x3,0xaa52,0x3,{43602|[82,170,0,0,0,0,0,0]},ENUM_TWO}
cpu3: {43602,0,-43602,0x3,0xaa52,0x3,{43602|[82,170,0,0,0,0,0,0]},ENUM_TWO}
}
72847: {
cpu0: {72847,0,-72847,0x3,0x11c8f,0x3,{72847|[143,28,1,0,0,0,0,0]},ENUM_THREE}
cpu1: {72847,0,-72847,0x3,0x11c8f,0x3,{72847|[143,28,1,0,0,0,0,0]},ENUM_THREE}
cpu2: {72847,0,-72847,0x3,0x11c8f,0x3,{72847|[143,28,1,0,0,0,0,0]},ENUM_THREE}
cpu3: {72847,0,-72847,0x3,0x11c8f,0x3,{72847|[143,28,1,0,0,0,0,0]},ENUM_THREE}
}
...
Signed-off-by: Yonghong Song <yhs@fb.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
2018-08-30 05:43:13 +08:00
|
|
|
static void htab_percpu_map_seq_show_elem(struct bpf_map *map, void *key,
|
|
|
|
struct seq_file *m)
|
|
|
|
{
|
|
|
|
struct htab_elem *l;
|
|
|
|
void __percpu *pptr;
|
|
|
|
int cpu;
|
|
|
|
|
|
|
|
rcu_read_lock();
|
|
|
|
|
|
|
|
l = __htab_map_lookup_elem(map, key);
|
|
|
|
if (!l) {
|
|
|
|
rcu_read_unlock();
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
btf_type_seq_show(map->btf, map->btf_key_type_id, key, m);
|
|
|
|
seq_puts(m, ": {\n");
|
|
|
|
pptr = htab_elem_get_ptr(l, map->key_size);
|
|
|
|
for_each_possible_cpu(cpu) {
|
|
|
|
seq_printf(m, "\tcpu%d: ", cpu);
|
|
|
|
btf_type_seq_show(map->btf, map->btf_value_type_id,
|
|
|
|
per_cpu_ptr(pptr, cpu), m);
|
|
|
|
seq_puts(m, "\n");
|
|
|
|
}
|
|
|
|
seq_puts(m, "}\n");
|
|
|
|
|
|
|
|
rcu_read_unlock();
|
|
|
|
}
|
|
|
|
|
2017-04-11 21:34:58 +08:00
|
|
|
const struct bpf_map_ops htab_percpu_map_ops = {
|
2018-01-12 12:29:05 +08:00
|
|
|
.map_alloc_check = htab_map_alloc_check,
|
2016-02-02 14:39:53 +08:00
|
|
|
.map_alloc = htab_map_alloc,
|
|
|
|
.map_free = htab_map_free,
|
|
|
|
.map_get_next_key = htab_map_get_next_key,
|
|
|
|
.map_lookup_elem = htab_percpu_map_lookup_elem,
|
|
|
|
.map_update_elem = htab_percpu_map_update_elem,
|
|
|
|
.map_delete_elem = htab_map_delete_elem,
|
bpf: add bpffs pretty print for percpu arraymap/hash/lru_hash
Added bpffs pretty print for percpu arraymap, percpu hashmap
and percpu lru hashmap.
For each map <key, value> pair, the format is:
<key_value>: {
cpu0: <value_on_cpu0>
cpu1: <value_on_cpu1>
...
cpun: <value_on_cpun>
}
For example, on my VM, there are 4 cpus, and
for test_btf test in the next patch:
cat /sys/fs/bpf/pprint_test_percpu_hash
You may get:
...
43602: {
cpu0: {43602,0,-43602,0x3,0xaa52,0x3,{43602|[82,170,0,0,0,0,0,0]},ENUM_TWO}
cpu1: {43602,0,-43602,0x3,0xaa52,0x3,{43602|[82,170,0,0,0,0,0,0]},ENUM_TWO}
cpu2: {43602,0,-43602,0x3,0xaa52,0x3,{43602|[82,170,0,0,0,0,0,0]},ENUM_TWO}
cpu3: {43602,0,-43602,0x3,0xaa52,0x3,{43602|[82,170,0,0,0,0,0,0]},ENUM_TWO}
}
72847: {
cpu0: {72847,0,-72847,0x3,0x11c8f,0x3,{72847|[143,28,1,0,0,0,0,0]},ENUM_THREE}
cpu1: {72847,0,-72847,0x3,0x11c8f,0x3,{72847|[143,28,1,0,0,0,0,0]},ENUM_THREE}
cpu2: {72847,0,-72847,0x3,0x11c8f,0x3,{72847|[143,28,1,0,0,0,0,0]},ENUM_THREE}
cpu3: {72847,0,-72847,0x3,0x11c8f,0x3,{72847|[143,28,1,0,0,0,0,0]},ENUM_THREE}
}
...
Signed-off-by: Yonghong Song <yhs@fb.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
2018-08-30 05:43:13 +08:00
|
|
|
.map_seq_show_elem = htab_percpu_map_seq_show_elem,
|
2020-01-16 02:43:04 +08:00
|
|
|
BATCH_OPS(htab_percpu),
|
2016-02-02 14:39:53 +08:00
|
|
|
};
|
|
|
|
|
2017-04-11 21:34:58 +08:00
|
|
|
const struct bpf_map_ops htab_lru_percpu_map_ops = {
|
2018-01-12 12:29:05 +08:00
|
|
|
.map_alloc_check = htab_map_alloc_check,
|
2016-11-12 02:55:10 +08:00
|
|
|
.map_alloc = htab_map_alloc,
|
|
|
|
.map_free = htab_map_free,
|
|
|
|
.map_get_next_key = htab_map_get_next_key,
|
|
|
|
.map_lookup_elem = htab_lru_percpu_map_lookup_elem,
|
|
|
|
.map_update_elem = htab_lru_percpu_map_update_elem,
|
|
|
|
.map_delete_elem = htab_lru_map_delete_elem,
|
bpf: add bpffs pretty print for percpu arraymap/hash/lru_hash
Added bpffs pretty print for percpu arraymap, percpu hashmap
and percpu lru hashmap.
For each map <key, value> pair, the format is:
<key_value>: {
cpu0: <value_on_cpu0>
cpu1: <value_on_cpu1>
...
cpun: <value_on_cpun>
}
For example, on my VM, there are 4 cpus, and
for test_btf test in the next patch:
cat /sys/fs/bpf/pprint_test_percpu_hash
You may get:
...
43602: {
cpu0: {43602,0,-43602,0x3,0xaa52,0x3,{43602|[82,170,0,0,0,0,0,0]},ENUM_TWO}
cpu1: {43602,0,-43602,0x3,0xaa52,0x3,{43602|[82,170,0,0,0,0,0,0]},ENUM_TWO}
cpu2: {43602,0,-43602,0x3,0xaa52,0x3,{43602|[82,170,0,0,0,0,0,0]},ENUM_TWO}
cpu3: {43602,0,-43602,0x3,0xaa52,0x3,{43602|[82,170,0,0,0,0,0,0]},ENUM_TWO}
}
72847: {
cpu0: {72847,0,-72847,0x3,0x11c8f,0x3,{72847|[143,28,1,0,0,0,0,0]},ENUM_THREE}
cpu1: {72847,0,-72847,0x3,0x11c8f,0x3,{72847|[143,28,1,0,0,0,0,0]},ENUM_THREE}
cpu2: {72847,0,-72847,0x3,0x11c8f,0x3,{72847|[143,28,1,0,0,0,0,0]},ENUM_THREE}
cpu3: {72847,0,-72847,0x3,0x11c8f,0x3,{72847|[143,28,1,0,0,0,0,0]},ENUM_THREE}
}
...
Signed-off-by: Yonghong Song <yhs@fb.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
2018-08-30 05:43:13 +08:00
|
|
|
.map_seq_show_elem = htab_percpu_map_seq_show_elem,
|
2020-01-16 02:43:04 +08:00
|
|
|
BATCH_OPS(htab_lru_percpu),
|
2016-11-12 02:55:10 +08:00
|
|
|
};
|
|
|
|
|
2018-01-12 12:29:05 +08:00
|
|
|
static int fd_htab_map_alloc_check(union bpf_attr *attr)
|
2017-03-23 01:00:34 +08:00
|
|
|
{
|
|
|
|
if (attr->value_size != sizeof(u32))
|
2018-01-12 12:29:05 +08:00
|
|
|
return -EINVAL;
|
|
|
|
return htab_map_alloc_check(attr);
|
2017-03-23 01:00:34 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
static void fd_htab_map_free(struct bpf_map *map)
|
|
|
|
{
|
|
|
|
struct bpf_htab *htab = container_of(map, struct bpf_htab, map);
|
|
|
|
struct hlist_nulls_node *n;
|
|
|
|
struct hlist_nulls_head *head;
|
|
|
|
struct htab_elem *l;
|
|
|
|
int i;
|
|
|
|
|
|
|
|
for (i = 0; i < htab->n_buckets; i++) {
|
|
|
|
head = select_bucket(htab, i);
|
|
|
|
|
|
|
|
hlist_nulls_for_each_entry_safe(l, n, head, hash_node) {
|
|
|
|
void *ptr = fd_htab_map_get_ptr(map, l);
|
|
|
|
|
|
|
|
map->ops->map_fd_put_ptr(ptr);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
htab_map_free(map);
|
|
|
|
}
|
|
|
|
|
2017-06-28 14:08:34 +08:00
|
|
|
/* only called from syscall */
|
|
|
|
int bpf_fd_htab_map_lookup_elem(struct bpf_map *map, void *key, u32 *value)
|
|
|
|
{
|
|
|
|
void **ptr;
|
|
|
|
int ret = 0;
|
|
|
|
|
|
|
|
if (!map->ops->map_fd_sys_lookup_elem)
|
|
|
|
return -ENOTSUPP;
|
|
|
|
|
|
|
|
rcu_read_lock();
|
|
|
|
ptr = htab_map_lookup_elem(map, key);
|
|
|
|
if (ptr)
|
|
|
|
*value = map->ops->map_fd_sys_lookup_elem(READ_ONCE(*ptr));
|
|
|
|
else
|
|
|
|
ret = -ENOENT;
|
|
|
|
rcu_read_unlock();
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2017-03-23 01:00:34 +08:00
|
|
|
/* only called from syscall */
|
|
|
|
int bpf_fd_htab_map_update_elem(struct bpf_map *map, struct file *map_file,
|
|
|
|
void *key, void *value, u64 map_flags)
|
|
|
|
{
|
|
|
|
void *ptr;
|
|
|
|
int ret;
|
|
|
|
u32 ufd = *(u32 *)value;
|
|
|
|
|
|
|
|
ptr = map->ops->map_fd_get_ptr(map, map_file, ufd);
|
|
|
|
if (IS_ERR(ptr))
|
|
|
|
return PTR_ERR(ptr);
|
|
|
|
|
|
|
|
ret = htab_map_update_elem(map, key, &ptr, map_flags);
|
|
|
|
if (ret)
|
|
|
|
map->ops->map_fd_put_ptr(ptr);
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
static struct bpf_map *htab_of_map_alloc(union bpf_attr *attr)
|
|
|
|
{
|
|
|
|
struct bpf_map *map, *inner_map_meta;
|
|
|
|
|
|
|
|
inner_map_meta = bpf_map_meta_alloc(attr->inner_map_fd);
|
|
|
|
if (IS_ERR(inner_map_meta))
|
|
|
|
return inner_map_meta;
|
|
|
|
|
2018-01-12 12:29:05 +08:00
|
|
|
map = htab_map_alloc(attr);
|
2017-03-23 01:00:34 +08:00
|
|
|
if (IS_ERR(map)) {
|
|
|
|
bpf_map_meta_free(inner_map_meta);
|
|
|
|
return map;
|
|
|
|
}
|
|
|
|
|
|
|
|
map->inner_map_meta = inner_map_meta;
|
|
|
|
|
|
|
|
return map;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void *htab_of_map_lookup_elem(struct bpf_map *map, void *key)
|
|
|
|
{
|
|
|
|
struct bpf_map **inner_map = htab_map_lookup_elem(map, key);
|
|
|
|
|
|
|
|
if (!inner_map)
|
|
|
|
return NULL;
|
|
|
|
|
|
|
|
return READ_ONCE(*inner_map);
|
|
|
|
}
|
|
|
|
|
2017-08-19 09:12:46 +08:00
|
|
|
static u32 htab_of_map_gen_lookup(struct bpf_map *map,
|
|
|
|
struct bpf_insn *insn_buf)
|
|
|
|
{
|
|
|
|
struct bpf_insn *insn = insn_buf;
|
|
|
|
const int ret = BPF_REG_0;
|
|
|
|
|
2018-06-03 05:06:35 +08:00
|
|
|
BUILD_BUG_ON(!__same_type(&__htab_map_lookup_elem,
|
|
|
|
(void *(*)(struct bpf_map *map, void *key))NULL));
|
|
|
|
*insn++ = BPF_EMIT_CALL(BPF_CAST_CALL(__htab_map_lookup_elem));
|
2017-08-19 09:12:46 +08:00
|
|
|
*insn++ = BPF_JMP_IMM(BPF_JEQ, ret, 0, 2);
|
|
|
|
*insn++ = BPF_ALU64_IMM(BPF_ADD, ret,
|
|
|
|
offsetof(struct htab_elem, key) +
|
|
|
|
round_up(map->key_size, 8));
|
|
|
|
*insn++ = BPF_LDX_MEM(BPF_DW, ret, ret, 0);
|
|
|
|
|
|
|
|
return insn - insn_buf;
|
|
|
|
}
|
|
|
|
|
2017-03-23 01:00:34 +08:00
|
|
|
static void htab_of_map_free(struct bpf_map *map)
|
|
|
|
{
|
|
|
|
bpf_map_meta_free(map->inner_map_meta);
|
|
|
|
fd_htab_map_free(map);
|
|
|
|
}
|
|
|
|
|
2017-04-11 21:34:58 +08:00
|
|
|
const struct bpf_map_ops htab_of_maps_map_ops = {
|
2018-01-12 12:29:05 +08:00
|
|
|
.map_alloc_check = fd_htab_map_alloc_check,
|
2017-03-23 01:00:34 +08:00
|
|
|
.map_alloc = htab_of_map_alloc,
|
|
|
|
.map_free = htab_of_map_free,
|
|
|
|
.map_get_next_key = htab_map_get_next_key,
|
|
|
|
.map_lookup_elem = htab_of_map_lookup_elem,
|
|
|
|
.map_delete_elem = htab_map_delete_elem,
|
|
|
|
.map_fd_get_ptr = bpf_map_fd_get_ptr,
|
|
|
|
.map_fd_put_ptr = bpf_map_fd_put_ptr,
|
2017-06-28 14:08:34 +08:00
|
|
|
.map_fd_sys_lookup_elem = bpf_map_fd_sys_lookup_elem,
|
2017-08-19 09:12:46 +08:00
|
|
|
.map_gen_lookup = htab_of_map_gen_lookup,
|
2018-08-12 07:59:17 +08:00
|
|
|
.map_check_btf = map_check_no_btf,
|
2017-03-23 01:00:34 +08:00
|
|
|
};
|