Ignore trailing kernel module annotation

[danobi]

Before, find_wildcard_matches would choke on lines
available_filter_functions like:

ehci_disable_ASE [ehci_hcd]

This patch has k[ret]probes ignore the module annotation.

This closes #1036 .

Checklist

• Language changes are updated in docs/reference_guide.md
• User-visible and non-trivial changes updated in CHANGELOG.md

[fbs]

Ah nice you beat me to it. Wonder if it makes sense to define kprobes like kprobe:module:func to be able to attach to "module functions" that overlap in name

[danobi]

Yeah, I think kprobe:module:func would work. And I think it could be done as a followup PR.

Do you think the following rules make sense?

• kprobe:foo*
  • ignore module name (module implicitly wildcarded)
• 'kprobe:*:foo*
  • ignore module name (module explicitly wildcarded)
• kprobe:bar*:foo*
  • don't ignore module name (not full wildcard)
• non-wildcard cases work as you'd expect -- full text match only

Or is this too complicated? The alternative is to abandon the logic changes in this PR (the cleanup commits I think are still good) and always require module param to be specified if you want to include module kprobes.

[fbs]

Or is this too complicated?

Sounds good

The alternative is to abandon the logic changes in this PR (the cleanup commits I think are still good) and always require module param to be specified if you want to include module kprobes.

I think we should land this asap, we can always refactor it later. There is quite a lot of duplicate code between the listing and the function finding and kaddr/ksym expansion that we can clean up and simplify.

[zhangjaycee]

Yeah, I think kprobe:module:func would work. And I think it could be done as a followup PR.

Do you think the following rules make sense?

• kprobe:foo*

  • ignore module name (module implicitly wildcarded)

• 'kprobe:*:foo*

  • ignore module name (module explicitly wildcarded)

• kprobe:bar*:foo*

  • don't ignore module name (not full wildcard)

• non-wildcard cases work as you'd expect -- full text match only

Or is this too complicated? The alternative is to abandon the logic changes in this PR (the cleanup commits I think are still good) and always require module param to be specified if you want to include module kprobes.

Hi, I wonder if there has been any progress or plans on this feature? It is exactly what we need recently. Thanks!

[viktormalik]

Hi, there is now support for this syntax for kfunc probes, i.e. kfunc:module:func. Is that sufficient for your needs?

[zhangjaycee]

Hi, there is now support for this syntax for kfunc probes, i.e. kfunc:module:func. Is that sufficient for your needs?

Functionally, kfunc:module:func is good. But I found it requires relatively new kernel version support. So I wonder if anyone plans to implement kprobe:module:func. If it is not in process, I would also appreciate it if anyone could give some suggestions on how to implement it. Thanks!

[viktormalik]

Functionally, kfunc:module:func is good. But I found it requires relatively new kernel version support. So I wonder if anyone plans to implement kprobe:module:func. If it is not in process, I would also appreciate it if anyone could give some suggestions on how to implement it. Thanks!

Yes, it requires kernel 5.5+ with BTF support, if you call that new :-).

Since we have this functionality, we don't plan to duplicate it for kprobes. If you want to do it yourself, you can get inspired by the kfunc implementation for some parts. The main difference will be in the way probes are attached. While kfunc specifies the target module/function upon BPF program loading, kprobes do that during the attachment itself. So, you'll have to check if (and how) BCC's bpf_attach_kprobe supports specifying the module to attach to.

[zhangjaycee]

Functionally, kfunc:module:func is good. But I found it requires relatively new kernel version support. So I wonder if anyone plans to implement kprobe:module:func. If it is not in process, I would also appreciate it if anyone could give some suggestions on how to implement it. Thanks!

Yes, it requires kernel 5.5+ with BTF support, if you call that new :-).

Since we have this functionality, we don't plan to duplicate it for kprobes. If you want to do it yourself, you can get inspired by the kfunc implementation for some parts. The main difference will be in the way probes are attached. While kfunc specifies the target module/function upon BPF program loading, kprobes do that during the attachment itself. So, you'll have to check if (and how) BCC's bpf_attach_kprobe supports specifying the module to attach to.

Thanks for the information :-). I will give feedback if there is any progress on this in the future.