On 9/28/19 8:30 AM, Andrii Nakryiko wrote:
This patch switches libbpf_num_possible_cpus() from using possible CPU
set to present CPU set. This fixes issues with incorrect auto-sizing of
PERF_EVENT_ARRAY map on HOTPLUG-enabled systems.
Those issues should be described in more detail here in the changelog,
otherwise noone knows what is meant exactly when glancing at the git log.
On HOTPLUG enabled systems, /sys/devices/system/cpu/possible is going to
be a set of any representable (i.e., potentially possible) CPU, which is
normally way higher than real amount of CPUs (e.g., 0-127 on VM I've
tested on, while there were just two CPU cores actually present).
/sys/devices/system/cpu/present, on the other hand, will only contain
CPUs that are physically present in the system (even if not online yet),
which is what we really want, especially when creating per-CPU maps or
perf events.
On systems with HOTPLUG disabled, present and possible are identical, so
there is no change of behavior there.
Signed-off-by: Andrii Nakryiko <andriin@xxxxxx>
---
tools/lib/bpf/libbpf.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
index e0276520171b..45351c074e45 100644
--- a/tools/lib/bpf/libbpf.c
+++ b/tools/lib/bpf/libbpf.c
@@ -5899,7 +5899,7 @@ void bpf_program__bpil_offs_to_addr(struct bpf_prog_info_linear *info_linear)
int libbpf_num_possible_cpus(void)
{
- static const char *fcpu = "/sys/devices/system/cpu/possible";
+ static const char *fcpu = "/sys/devices/system/cpu/present";
Problem is that this is going to break things *badly* for per-cpu maps as
BPF_DECLARE_PERCPU() relies on possible CPUs, not present ones. And given
present<=possible you'll end up corrupting user space when you do a lookup
on the map since kernel side operates on possible as well.
int len = 0, n = 0, il = 0, ir = 0;
unsigned int start = 0, end = 0;
int tmp_cpus = 0;
