Fix probe attachment failure when CPU 0 is offline

[Copilot]

On systems where CPU 0 is offline (e.g., AArch64 embedded devices using CPU hotplug), BCC tools fail to attach kprobes/tracepoints because perf_event_open is called with a hardcoded cpu=0, returning ENODEV.

Changes

• src/cc/libbpf.c: Added get_first_online_cpu() helper that reads /sys/devices/system/cpu/online to find the lowest-numbered online CPU, falling back to 0 if the file is unreadable.

• Replaced int cpu = 0 with int cpu = get_first_online_cpu() in two functions:

  • bpf_try_perf_event_open_with_probe — used for kprobe/uprobe PMU-based attachment
  • bpf_attach_tracing_event — used for tracefs-based tracepoint/kprobe attachment

The existing logic that overrides cpu to -1 when a PID filter is active is preserved unchanged. Only the default (all-CPU, all-process) path is affected.

// /sys/devices/system/cpu/online contains a sorted range list, e.g. "1-7" or "2,4-7"
// fscanf("%d") stops at the first non-digit, yielding the first online CPU.
static int get_first_online_cpu(void) {
    FILE *fp = fopen("/sys/devices/system/cpu/online", "r");
    int cpu = 0;
    if (!fp) return 0;
    if (fscanf(fp, "%d", &cpu) != 1) cpu = 0;
    fclose(fp);
    return cpu;
}

Original prompt

---

This section details on the original issue you should resolve

<issue_title>Hardcoded cpu=0 in embedded libbpf causes probe attachment failure when CPU 0 is offline</issue_title>
<issue_description>### Description
The embedded version of libbpf within BCC (located at src/cc/libbpf) contains several instances where cpu is hardcoded to 0 when calling
perf_event_open. This causes BCC tools to fail on systems where CPU 0 is offline (e.g., embedded devices using CPU hotplug for power saving or isolation).

Reproduction Steps

1. On a Linux system (e.g., AArch64 Android/Embedded), offline CPU 0:
   echo 0 > /sys/devices/system/cpu/cpu0/online
   2.Run a BCC tool that uses kprobes or tracepoints (e.g., execsnoop):
   ./execsnoop

Expected Behavior: The tool should attach probes successfully using any available online CPU.
Actual Behavior: The tool fails to start. The internal error (if traced) shows perf_event_open failing with ENODEV because it explicitly requests CPU 0.

Technical Details & Analysis

I encountered this issue on an AArch64 environment where CPU 0 is offline. I traced the failure to the
libbpf.c file inside the BCC tree.There are multiple functions where cpu is explicitly set to 0. For example:

1. bpf_attach_tracing_event
   // src/cc/libbpf/src/libbpf.c static int bpf_attach_tracing_event(...) { // ... int cpu = 0; // <--- Hardcoded // ... pfd = perf_event_open(&attr, pid, cpu, group_fd, 0); }

2.bpf_object__probe_loading: This function attempts to load a trivial BPF program to check if BPF is supported. It hardcodes a check on CPU 0 logic implicitly or via minimal validation that fails if the underlying resources assume CPU 0 availability.
3.Legacy Probe Openers: Functions like perf_event_open_probe perf_event_kprobe_open_legacy, and perf_event_uprobe_open_legacy also exhibit this pattern.

Proposed Fix

I was able to resolve this locally by patching libbpf.c to dynamically find the first online CPU instead of assuming 0.
A helper function like this was introduced:
static int get_first_online_cpu(void) { // parses /sys/devices/system/cpu/online to find the first enabled CPU }
And then replacing int cpu = 0; with int cpu = get_first_online_cpu(); in the affected functions.</issue_description>

Comments on the Issue (you are @copilot in this section)

• Fixes Hardcoded cpu=0 in embedded libbpf causes probe attachment failure when CPU 0 is offline #5450

---

💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.