Kprobe event never deleted when maxactive fails

[pchaigno]

Support for the kprobe maxactive parameter was added in #39 with a fallback in case the kernel doesn't support maxactive through debugfs. That fallback code is leaving a kprobe behind.

When setting the kprobe event, if the kernel does not support maxactive, the write operation to kprobe_events does not return an error. To check whether the kprobe setup was successful, gobpf attempts to read the id file of the kprobe. If no such file exists, then a new kprobe event is created without the maxactive value.

However, the write to kprobe_events does not return an error because it actually succeeds. The kernel just creates the kprobe event under a different name. Therefore, gobpf leaves that first kprobe event with a different name and never deletes it. You should be able to see that event under /sys/kernel/debug/tracing/events/kprobes/.

Note that I don't have a gobpf environment set up, and thus, I did not try to (re)produce the bug; I found this while reading the code to try and expose maxactive in bcc as well. I might be missing something.

/cc @alban @iaguis

[suprememoocow]

Note that I don't have a gobpf environment set up, and thus, I did not try to (re)produce the bug; I found this while reading the code to try and expose maxactive in bcc as well. I might be missing something.

I can confirm that I'm seeing this issue when I use maxactive value of -1: https://gitlab.com/andrewn/gitalymon/blob/master/gitalymon.go#L135-139