static void ebpf_cleanup_disk_list(void)
{
    netdata_ebpf_disks_t *move = disk_list;
    while (move) {
        netdata_ebpf_disks_t *next = move->next;

        freez(move);

        move = next;
    }

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="src/collectors/ebpf.plugin/ebpf_vfs.c">

<violation number="1" location="src/collectors/ebpf.plugin/ebpf_vfs.c:1343">
P2: The cgroup aggregation now takes the max of each per-PID counter instead of summing them, which undercounts cgroup totals whenever more than one PID contributes. Since each `pids->vfs` is a per-PID snapshot, the aggregation should still sum across PIDs (and handle monotonicity separately if needed).</violation>
</file>

<file name="src/collectors/ebpf.plugin/ebpf_disk.c">

<violation number="1" location="src/collectors/ebpf.plugin/ebpf_disk.c:489">
P2: The new `has_resources` guard skips cleanup when tracepoints were enabled by this thread but no other resources were allocated (e.g., `read_local_disks()` fails after enable). Since `was_block_*_enabled` is 0 when this module enables the tracepoints, `has_resources` remains false and `ebpf_disk_disable_tracepoints()` is never called, leaving tracepoints enabled. Track whether this thread enabled tracepoints (or restore the previous `disk_safe_clean` logic) so cleanup always runs in that case.</violation>
</file>

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="src/collectors/ebpf.plugin/ebpf_disk.c">

<violation number="1" location="src/collectors/ebpf.plugin/ebpf_disk.c:490">
P2: Cleanup is skipped if ebpf_disk_enable_tracepoints() fails, even though mutexes were already initialized. That can leave initialized mutexes/resources around and make later restarts unsafe. Consider enabling cleanup as soon as those resources are allocated (or restoring the resource-based check) so failure paths still destroy them.</violation>
</file>

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="src/collectors/ebpf.plugin/ebpf_hardirq.c">

<violation number="1" location="src/collectors/ebpf.plugin/ebpf_hardirq.c:216">
P2: The new early return in hardirq_cleanup skips unloading tracepoints/BPF objects when hardirq_safe_clean is false, which can leave probes attached on early failure paths. Keep the cleanup logic running even when the safe-clean flag is false, and only skip chart obsoletion.</violation>
</file>

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="src/collectors/ebpf.plugin/ebpf_hardirq.c">

<violation number="1" location="src/collectors/ebpf.plugin/ebpf_hardirq.c:231">
P1: The hardirq BPF load/attach logic is fully commented out, so `ebpf_hardirq_load_bpf` always returns success without loading any program. The thread continues as if load succeeded, which leaves the collector running with no attached BPF programs and no data collected.</violation>
</file>

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="src/collectors/ebpf.plugin/ebpf_hardirq.c">

<violation number="1" location="src/collectors/ebpf.plugin/ebpf_hardirq.c:250">
P2: Don’t skip destroying the libbpf object during cleanup. Leaving the destroy call commented out leaks BPF maps/links and file descriptors, and can keep resources attached until process exit.</violation>
</file>

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="src/collectors/ebpf.plugin/ebpf_hardirq.c">

<violation number="1" location="src/collectors/ebpf.plugin/ebpf_hardirq.c:222">
P0: The unconditional early return disables the HardIRQ collector thread, making the module non-functional.</violation>
</file>