[RFC PATCH v1 0/1] tracing/kprobe: Add multi-probe support for 'perf_kprobe' PMU

[Francis Laniel <flaniel@linux.microsoft.com>]

Hi.


In the kernel source code, it exists different functions which share the same
name but which have, of course, different addresses as they can be defined in
different modules.
This is, for example, the case with ntfs_file_write_iter() which exists both in
the "old" NTFS module and in the "new" NTFS3 module.
When you create a perf_kprobe PMU for such a function, it will only be created
for the first one (i.e. the one with the lowest address):
root@vm-amd64:~# grep ntfs_file_write_iter /proc/kallsyms
ffffffff814c5c20 t __pfx_ntfs_file_write_iter
ffffffff814c5c30 t ntfs_file_write_iter
ffffffff814f41f0 t __pfx_ntfs_file_write_iter
ffffffff814f4200 t ntfs_file_write_iter
root@vm-amd64:/mnt# mount | grep /mnt
/foo.img on /mnt type ntfs3 (rw,relatime,uid=0,gid=0,iocharset=utf8)
# ig is a tool which installs a PMU kprobe on ntfs_file_write_iter().
root@vm-amd64:/mnt# ig trace fsslower -m 0 -f ntfs3 --host &> /tmp/foo &
[1] 207
root@vm-amd64:/mnt# dd if=./foo of=./bar count=3
3+0 records in
3+0 records out
1536 bytes (1.5 kB, 1.5 KiB) copied, 0.00543323 s, 283 kB/s
root@vm-amd64:/mnt# fg
ig trace fsslower -m 0 -f ntfs3 --host &> /tmp/foo
^Croot@vm-amd64:/mnt# more /tmp/foo
RUNTIME.CONTAINERNAME          RUNTIME.CONTAIN… PID              COMM
  T      BYTES     OFFSET        LAT FILE
                                                214              dd
  R        512          0        766 foo
                                                214              dd
  R        512        512          9 foo
                                                214              dd
As you can see, only read events are reported and not the open and write ones.

So, with this contribution, I added multi-probe support for perf_kprobe PMU.
The idea is to create a trace_kprobe for each address which correspond to the
given symbol.
All these different trace_kprobe will be linked together by sharing the same
trace_probe.
As a consequence, all these trace_kprobes are registered and the above problem
is solved:
root@vm-amd64:/mnt# ig trace fsslower -m 0 -f ntfs3 --host &> /tmp/foo &
[1] 210
root@vm-amd64:/mnt# dd if=./foo of=./bar count=3
3+0 records in
3+0 records out
1536 bytes (1.5 kB, 1.5 KiB) copied, 0.00624642 s, 246 kB/s
root@vm-amd64:/mnt# fg
ig trace fsslower -m 0 -f ntfs3 --host &> /tmp/foo
^C
root@vm-amd64:/mnt# more /tmp/foo
RUNTIME.CONTAINERNAME          RUNTIME.CONTAIN… PID              COMM
  T      BYTES     OFFSET        LAT FILE
                                                217              dd
  O          0          0          8 foo
                                                217              dd
  O          0          0          6 bar
                                                217              dd
  R        512          0       1064 foo
                                                217              dd
  W        512          0        267 bar
                                                217              dd
  R        512        512          8 foo
                                                217              dd
  W        512        512        238 bar
                                                217              dd
  R        512       1024          6 foo
                                                217              dd
  W        512       1024          8 bar
Note that, we also get the open events as ntfs_file is also defined twice.

I marked this contribution as RFC as I first would like to get your opinion on
it.
Moreover, as I am not a kprobe expert, this is possible that I made mistake (I
am not really sure if all the trace_kprobes linked with append_trace_kprobe()
are freed together).
So, if you see any way to improve this contribution, feel free to share.

Francis Laniel (1):
  tracing/kprobe: Add multi-probe support for 'perf_kprobe' PMU

 kernel/trace/trace_kprobe.c | 86 +++++++++++++++++++++++++++++++++++++
 1 file changed, 86 insertions(+)


Best regards and thank you in advance.
--
2.34.1