summaryrefslogtreecommitdiffstats
path: root/kernel/bpf
diff options
context:
space:
mode:
authorEric Dumazet <edumazet@google.com>2020-12-21 11:25:06 -0800
committerDaniel Borkmann <daniel@iogearbox.net>2020-12-22 00:14:31 +0100
commite7e518053c267bb6be3799520d9f4a34c7264a2e (patch)
treeed7913c37a9b08f46559a5a6a741725ffcd6d1e5 /kernel/bpf
parentd467d80dc399ba77875d647f2f37b7d1a70d94c2 (diff)
downloadlinux-stable-e7e518053c267bb6be3799520d9f4a34c7264a2e.tar.gz
linux-stable-e7e518053c267bb6be3799520d9f4a34c7264a2e.tar.bz2
linux-stable-e7e518053c267bb6be3799520d9f4a34c7264a2e.zip
bpf: Add schedule point in htab_init_buckets()
We noticed that with a LOCKDEP enabled kernel, allocating a hash table with 65536 buckets would use more than 60ms. htab_init_buckets() runs from process context, it is safe to schedule to avoid latency spikes. Fixes: c50eb518e262 ("bpf: Use separate lockdep class for each hashtab") Reported-by: John Sperbeck <jsperbeck@google.com> Signed-off-by: Eric Dumazet <edumazet@google.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Acked-by: Song Liu <songliubraving@fb.com> Link: https://lore.kernel.org/bpf/20201221192506.707584-1-eric.dumazet@gmail.com
Diffstat (limited to 'kernel/bpf')
-rw-r--r--kernel/bpf/hashtab.c1
1 files changed, 1 insertions, 0 deletions
diff --git a/kernel/bpf/hashtab.c b/kernel/bpf/hashtab.c
index 7e848200cd26..c1ac7f964bc9 100644
--- a/kernel/bpf/hashtab.c
+++ b/kernel/bpf/hashtab.c
@@ -152,6 +152,7 @@ static void htab_init_buckets(struct bpf_htab *htab)
lockdep_set_class(&htab->buckets[i].lock,
&htab->lockdep_key);
}
+ cond_resched();
}
}