[GuillaumeLagrange]

Stop memtrack from printing libbpf warnings when it runs inside a user namespace with a delegated BPF token.

In that setup, two expected failures each printed warnings at the default log level, although memtrack recovers from both:

libbpf: Failed to bump RLIMIT_MEMLOCK (err = -EPERM), you might need to do it explicitly!
libbpf: failed to determine tracepoint 'kmem/rss_stat' perf event ID: -EACCES
libbpf: prog 'tracepoint_rss_stat': failed to create tracepoint 'kmem/rss_stat' perf event: -EACCES
[WARN  memtrack::ebpf::memtrack::tracking] Failed to attach rss_stat tracepoint, RSS collection disabled: ...

• rss_stat: kmem/rss_stat is a classic tracepoint. libbpf reads its id from tracefs, which checks access against the init user namespace, so the read fails with EACCES even with CAP_BPF and CAP_PERFMON. The delegated token can't help, because this path never calls bpf(). Physical-memory peaks come from the rmap fentry probes, which still attach through the token. Losing rss_stat removes only its cross-check and the cur_rss series.
• RLIMIT_MEMLOCK: libbpf raised the limit itself, the same setrlimit(RLIM_INFINITY) memtrack already makes and tolerates failing. libbpf's attempt is now disabled (libbpf_set_memlock_rlim(0)). Memtrack's own raise moves from after the skeleton load, where it had no effect on kernels older than 5.11, to before it.
• libbpf logging: libbpf output now goes through the logger under the libbpf target, so CODSPEED_LOG filters it (e.g. CODSPEED_LOG=warn,libbpf=debug). Before, it went straight to stderr at info level and above. During the rss_stat attach, libbpf messages are logged at debug, and so is memtrack's own message about the failure.

I ran each step inside the sandboxed setup above with codspeed exec -m memory -- /bin/true. At CODSPEED_LOG=info, there are no libbpf lines and no warnings. At CODSPEED_LOG=debug, there are about 4.2k [DEBUG libbpf] lines, and the same run collects about 3k events. The final revision, which logs at debug during the attach, compiles and passes clippy, but has not run in that environment.

Closes COD-3991

[greptile-apps]

Confidence Score: 5/5

[Medium impact] The PR appears safe to merge; no actionable defects were found.

Summary

Routes libbpf messages through the logger and quiets expected warnings when memtrack uses a delegated BPF token.

• Memtrack's libbpf messages follow its log filter.
• Memtrack sets its BPF memory limit before loading programs.

Acknowledgment: GuillaumeLagrange explicitly describes demoting both libbpf’s rss_stat attach messages and memtrack’s failure message to debug as intentional.

_{Reviews (1) · Last reviewed commit: "fix(memtrack): route libbpf output throu..." · Reviewed by Greptile}

[codspeed]

Merging this PR will degrade performance by 13.04%

2 warnings

⚠️ Walltime results may be unreliable

Some benchmarks used the Walltime instrument outside CodSpeed Macro Runners, which can make the results inconsistent.

Learn more about Macro Runners

See affected benchmarks

⚠️ 8 benchmarks are dominated by system calls

System calls cannot be simulated consistently and are left out of the measure. The reported value understates the real cost. Switch to the Walltime instrument to measure them.

Learn more about system calls

See affected benchmarks

❌ 1 regressed benchmark
✅ 40 untouched benchmarks
⏩ 6 skipped benchmarks¹

Warning

Please fix the performance issues or acknowledge them on CodSpeed.

Performance Changes

	Mode	Benchmark	BASE	HEAD	Efficiency
❌	Walltime	memtrack track tar	8.2 s	9.4 s	-13.04%

Tip

Investigate this regression by commenting @codspeedbot fix this regression on this PR, or directly use the CodSpeed MCP with your agent.

---

_{Comparing cod-3991-handle-unavailable-rss_stat-tracepoint-on-gen-2-macro (94f9d16) with main (ea54386)}

Footnotes

1. 6 benchmarks were skipped, so the baseline results were used instead. If they were deleted from the codebase, click here and archive them to remove them from the performance reports. ↩

[not-matthias]

we don't really need this anymore after we merge #531, right?

[GuillaumeLagrange]

I think we do though, it's for libbpf loggin not really memtrack logging