…22247)

(cherry picked from commit 531d549)

…spin (netdata#22232)

* ebpf.plugin: fix PID accounting shared-memory pool leak and 100% CPU spin

The eBPF plugin's per-PID shared-memory pool (32,768 slots backing
/dev/shm/netdata_shm_integration_ebpf) monotonically fills on any host
with normal process churn, and once the pool is exhausted each module's
apps-read loop spins one CPU core at 100% indefinitely.

ROOT CAUSE

netdata_ebpf_get_shm_pointer_unsafe() is an allocate-AND-set-bit API,
but it is called from two incompatible contexts:

  1. The per-module BPF map iteration (ebpf_read_*_apps_table), which
     is paired with netdata_ebpf_reset_shm_pointer_unsafe() via the
     kill(pid, 0) == ESRCH branch. This is a correct producer/consumer.

  2. The apps and cgroup aggregation helpers (*_sum_pids,
     *_update_*_cgroup, *_resume_apps_data), which iterate live-PID
     lists built from /proc and cgroup snapshots and call the same
     allocating accessor. These paths have NO reset counterpart.

Every second, for every live PID seen in /proc or a tracked cgroup,
every enabled eBPF module unconditionally sets its bit in the shm
slot for that PID. A dead PID's bit is only cleared by the owning
module's BPF-map iteration - but the BPF map's entry was already
deleted in the same cycle (by bpf_map_delete_elem inside
reset_shm_pointer_unsafe), so the next iteration cannot find the PID
and the bit is stuck forever. The slot therefore never reaches
threads == 0 and is never compacted out. Over 15h on a workstation
with ~1,300 live PIDs the pool reaches 100% with ~96% stale entries.

Once the pool is full, get_shm_pointer_unsafe() returns NULL. Every
apps_read loop had a bare `continue;` after the NULL check, which
skipped the `key = next_key;` advance, so bpf_map_get_next_key()
re-returned the same key forever and the thread spun at 100% CPU.

FIXES

  A. Split allocation from lookup. Introduce
     netdata_ebpf_lookup_shm_pointer_unsafe(pid) that returns the
     existing slot or NULL and sets no bit. Replace the 16 aggregation
     call sites with the new API. Keep get_shm_pointer_unsafe() at the
     8 BPF-map iteration call sites where allocation is legitimate and
     paired with reset. Aggregation paths additionally gate on the
     module bit being set so they do not consume zero-initialised
     per-module sub-structs.

  B. Replace `continue;` with `goto end_*_loop;` in all 8 apps-read
     loops so `key = next_key;` always runs, preventing the infinite
     loop even when the pool is legitimately exhausted.

  C. Zero freshly-allocated slots. ebpf_find_or_create_index_pid()
     now memset()s the slot on the create branch, so compacted tails
     and PID reuse cannot leak stale bits or stale per-module
     counters into new occupants.

  D. Use the correct kill() error check. Five modules used
     `if (kill(pid, 0))`, which treats EPERM (cross-UID processes) as
     "process is dead" and erroneously deletes the live process's
     kernel BPF map entry and zeroes its shm data. Switched all of
     them to `if (kill(pid, 0) == -1 && errno == ESRCH)`, matching
     the two modules that already did it correctly. Also applied to
     ebpf_parse_proc_files().

  E. Collapse ebpf_reset_specific_pid_data() to its effective body.
     thread_collecting only ever has NETDATA_EBPF_PIDS_PROC_FILE set,
     so the `idx < PROC_FILE` switch was dead code. The function now
     just forwards to ebpf_del_pid_entry(). The only other reader of
     that bitmask, ebpf_release_pid_data(), had zero callers and was
     removed.

  F. Sweep the shm pool on module exit. New helper
     netdata_ebpf_sweep_shm_for_module_unsafe() clears this module's
     bit across every shm slot and lets the existing compaction path
     release slots that become empty. All eight per-PID modules now
     call it under the shm semaphore in their *_exit path, so runtime
     module restarts no longer leak bits.

VERIFICATION

  - Root cause was captured on a live ebpf.plugin pinned at 64% CPU.
    gdb showed an EBPF_READ_FD thread permanently alternating
    bpf_map_get_next_key/bpf_map_lookup_elem at ebpf_fd.c:770-774,
    and ebpf_stat_values = {total = 32768, current = 32768} while
    ps showed 1,307 live PIDs.

  - The diagnosis was independently confirmed by a parallel review
    (codex, qwen, glm, minimax, opus), all converging on the
    alloc-without-reset asymmetry in the aggregation paths.

  - The modified tree builds cleanly (`cmake --build build --target
    ebpf.plugin`). No new warnings in the changed files; only the
    pre-existing vendored-Judy stringop-overflow warnings remain.

* ebpf.plugin: wipe shm on init, unlink on cleanup, drop unused out-param

Close two residual issues around the per-PID shared-memory integration
pool, spotted post-merge:

1. The POSIX shm object `netdata_shm_integration_ebpf` was neither
   truncated on open nor unlinked on shutdown. `shm_open(..., O_CREAT)`
   on an existing object just reopens it, and `ftruncate` to the
   previous size is a no-op, so the 14 MB mapped region retained the
   previous plugin run's bytes. The slot-allocation path memsets each
   new slot, so this was not a correctness bug — but every slot in
   `[current, total)` kept stale PID numbers and per-module counters
   until system reboot. Now:
   - `netdata_integration_initialize_shm()` memsets the whole mapped
     region immediately after `nd_mmap`, so the next plugin instance
     always starts from a clean slab.
   - `netdata_integration_cleanup_shm()` calls `shm_unlink` so a
     clean shutdown removes the backing object from `/dev/shm`.

2. Drop the unused `bool *created` out-parameter on
   `ebpf_find_or_create_index_pid()`. It was added when the memset
   was factored out of the allocation path; since the memset now
   lives inside the function, no caller needs to know whether the
   slot was freshly allocated. Reported by Copilot on PR netdata#22232.

* ebpf.plugin: address Copilot findings on 22232

Four residual issues spotted by Copilot after the initial round of
changes. All valid.

1. get_shm_pointer_unsafe() no longer bails out when the pool is full.
   The caller path for an already-tracked PID must still reach its
   slot so module bits can be updated or cleared. The inner
   ebpf_find_or_create_index_pid() already returns existing slots
   unconditionally and only rejects *new* allocations when full, so
   the redundant outer guard was both dead weight and actively
   harmful — it made existing PIDs unreachable the moment the pool
   filled.

2. Semaphore lifecycle. netdata_integration_initialize_shm() now
   sem_unlinks NETDATA_EBPF_SHM_INTEGRATION_NAME before sem_open, and
   netdata_integration_cleanup_shm() sem_unlinks on the way out. If
   a previous plugin instance crashed while holding the semaphore,
   sem_open(O_CREAT) on the same name would reuse the existing
   semaphore at its last value (O_CREAT's initial-value argument is
   ignored when the semaphore already exists), and the next run
   would spin on sem_timedwait() timeouts forever. Unlinking
   guarantees the initial value of 1 is honoured.

3. Socket apps iteration: the kernel-map delete for a dead socket
   tuple used to run inside `if (local_pid) { ... }`. When the shm
   pool is full and local_pid is NULL, `deleted` sockets were left
   in the BPF map to be re-iterated every cycle, growing the map
   unbounded. Moved bpf_map_delete_elem(fd, &key) outside the
   local_pid branch; it is conditioned only on `deleted`, which
   captures the socket's own freshness signal and is independent of
   shm pool state. (For SOCKET_IDX the generic
   reset_shm_pointer_unsafe() intentionally skips the delete, since
   the socket map is keyed by a tuple, not by pid — comment added.)

(cherry picked from commit bd38550)

…22231)

(cherry picked from commit c6bd0d0)