@RonFed What problem does this solve? This defeats the purpose of the probe. Rlimit being set to infinity doesn't mean the kernel has memcg accounting.

@RonFed What problem does this solve? This defeats the purpose of the probe. Rlimit being set to infinity doesn't mean the kernel has memcg accounting.

The main motivation is to avoid CAP_SYS_RESOURCE when it's not required. Performing the rlimit raise requires this capability, and if the process already runs with an infinite memlock limit — for example, via LimitMEMLOCK=infinity in a systemd unit file — it's not needed. If the kernel has memcg accounting the behavior is unchanged (no-op either way); if it doesn't, RemoveMemlock is already a no-op since the limit is infinite. This acts as an early detection of that case without requiring unnecessary privileges.

Okay, but your proposed fix still disables the probe, which is not what you'd want under any circumstance. There's also no guarantee that code running in between the probe and the first BPF() syscall doesn't lower rlimit. The import side effect of package rlimit doesn't crash or otherwise interfere with the Go program, and its result is memoized until for RemoveMemlock.

Your program should tolerate errors from RemoveMemlock in order to run successfully without CAP_SYS_RESOURCE. It doesn't seem like we've documented the fact that the returned error wraps an ErrNotSupported, though. Maybe that could be changed.