Skip to content

Commit 0ec13f6

Browse files
yonghong-songkernel-patches-bot
authored andcommitted
If a bucket contains a lot of sockets, during bpf_iter traversing
a bucket, concurrent userspace bpf_map_update_elem() and bpf program bpf_sk_storage_{get,delete}() may experience some undesirable delays as they will compete with bpf_iter for bucket lock. Note that the number of buckets for bpf_sk_storage_map is roughly the same as the number of cpus. So if there are lots of sockets in the system, each bucket could contain lots of sockets. Different actual use cases may experience different delays. Here, using selftest bpf_iter subtest bpf_sk_storage_map, I hacked the kernel with ktime_get_mono_fast_ns() to collect the time when a bucket was locked during bpf_iter prog traversing that bucket. This way, the maximum incurred delay was measured w.r.t. the number of elements in a bucket. # elems in each bucket delay(ns) 64 17000 256 72512 2048 875246 The potential delays will be further increased if we have even more elemnts in a bucket. Using rcu_read_lock() is a reasonable compromise here. It may lose some precision, e.g., access stale sockets, but it will not hurt performance of bpf program or user space application which also tries to get/delete or update map elements. Cc: Martin KaFai Lau <[email protected]> Acked-by: Song Liu <[email protected]> Signed-off-by: Yonghong Song <[email protected]> --- net/core/bpf_sk_storage.c | 21 ++++++++------------- 1 file changed, 8 insertions(+), 13 deletions(-) Changelog: v1 -> v2: - added some performance number. (Song) - tried to silence some sparse complains. but still has some left like context imbalance in "..." - different lock contexts for basic block which the code is too hard for sparse to analyze. (Jakub)
1 parent c63f2e8 commit 0ec13f6

File tree

1 file changed

+8
-13
lines changed

1 file changed

+8
-13
lines changed

net/core/bpf_sk_storage.c

Lines changed: 8 additions & 13 deletions
Original file line numberDiff line numberDiff line change
@@ -678,6 +678,7 @@ struct bpf_iter_seq_sk_storage_map_info {
678678
static struct bpf_local_storage_elem *
679679
bpf_sk_storage_map_seq_find_next(struct bpf_iter_seq_sk_storage_map_info *info,
680680
struct bpf_local_storage_elem *prev_selem)
681+
__acquires(RCU) __releases(RCU)
681682
{
682683
struct bpf_local_storage *sk_storage;
683684
struct bpf_local_storage_elem *selem;
@@ -701,7 +702,7 @@ bpf_sk_storage_map_seq_find_next(struct bpf_iter_seq_sk_storage_map_info *info,
701702
if (!selem) {
702703
/* not found, unlock and go to the next bucket */
703704
b = &smap->buckets[bucket_id++];
704-
raw_spin_unlock_bh(&b->lock);
705+
rcu_read_unlock();
705706
skip_elems = 0;
706707
break;
707708
}
@@ -715,7 +716,7 @@ bpf_sk_storage_map_seq_find_next(struct bpf_iter_seq_sk_storage_map_info *info,
715716

716717
for (i = bucket_id; i < (1U << smap->bucket_log); i++) {
717718
b = &smap->buckets[i];
718-
raw_spin_lock_bh(&b->lock);
719+
rcu_read_lock();
719720
count = 0;
720721
hlist_for_each_entry(selem, &b->list, map_node) {
721722
sk_storage = rcu_dereference_raw(selem->local_storage);
@@ -726,7 +727,7 @@ bpf_sk_storage_map_seq_find_next(struct bpf_iter_seq_sk_storage_map_info *info,
726727
}
727728
count++;
728729
}
729-
raw_spin_unlock_bh(&b->lock);
730+
rcu_read_unlock();
730731
skip_elems = 0;
731732
}
732733

@@ -801,18 +802,12 @@ static int bpf_sk_storage_map_seq_show(struct seq_file *seq, void *v)
801802
}
802803

803804
static void bpf_sk_storage_map_seq_stop(struct seq_file *seq, void *v)
805+
__releases(RCU)
804806
{
805-
struct bpf_iter_seq_sk_storage_map_info *info = seq->private;
806-
struct bpf_local_storage_map *smap;
807-
struct bpf_local_storage_map_bucket *b;
808-
809-
if (!v) {
807+
if (!v)
810808
(void)__bpf_sk_storage_map_seq_show(seq, v);
811-
} else {
812-
smap = (struct bpf_local_storage_map *)info->map;
813-
b = &smap->buckets[info->bucket_id];
814-
raw_spin_unlock_bh(&b->lock);
815-
}
809+
else
810+
rcu_read_unlock();
816811
}
817812

818813
static int bpf_iter_init_sk_storage_map(void *priv_data,

0 commit comments

Comments
 (0)