fprobe.rst 6.9 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198
  1. .. SPDX-License-Identifier: GPL-2.0
  2. ==================================
  3. Fprobe - Function entry/exit probe
  4. ==================================
  5. .. Author: Masami Hiramatsu <mhiramat@kernel.org>
  6. Introduction
  7. ============
  8. Fprobe is a function entry/exit probe based on the function-graph tracing
  9. feature in ftrace.
  10. Instead of tracing all functions, if you want to attach callbacks on specific
  11. function entry and exit, similar to the kprobes and kretprobes, you can
  12. use fprobe. Compared with kprobes and kretprobes, fprobe gives faster
  13. instrumentation for multiple functions with single handler. This document
  14. describes how to use fprobe.
  15. The usage of fprobe
  16. ===================
  17. The fprobe is a wrapper of ftrace (+ kretprobe-like return callback) to
  18. attach callbacks to multiple function entry and exit. User needs to set up
  19. the `struct fprobe` and pass it to `register_fprobe()`.
  20. Typically, `fprobe` data structure is initialized with the `entry_handler`
  21. and/or `exit_handler` as below.
  22. .. code-block:: c
  23. struct fprobe fp = {
  24. .entry_handler = my_entry_callback,
  25. .exit_handler = my_exit_callback,
  26. };
  27. To enable the fprobe, call one of register_fprobe(), register_fprobe_ips(), and
  28. register_fprobe_syms(). These functions register the fprobe with different types
  29. of parameters.
  30. The register_fprobe() enables a fprobe by function-name filters.
  31. E.g. this enables @fp on "func*()" function except "func2()".::
  32. register_fprobe(&fp, "func*", "func2");
  33. The register_fprobe_ips() enables a fprobe by ftrace-location addresses.
  34. E.g.
  35. .. code-block:: c
  36. unsigned long ips[] = { 0x.... };
  37. register_fprobe_ips(&fp, ips, ARRAY_SIZE(ips));
  38. And the register_fprobe_syms() enables a fprobe by symbol names.
  39. E.g.
  40. .. code-block:: c
  41. char syms[] = {"func1", "func2", "func3"};
  42. register_fprobe_syms(&fp, syms, ARRAY_SIZE(syms));
  43. To disable (remove from functions) this fprobe, call::
  44. unregister_fprobe(&fp);
  45. You can temporally (soft) disable the fprobe by::
  46. disable_fprobe(&fp);
  47. and resume by::
  48. enable_fprobe(&fp);
  49. The above is defined by including the header::
  50. #include <linux/fprobe.h>
  51. Same as ftrace, the registered callbacks will start being called some time
  52. after the register_fprobe() is called and before it returns. See
  53. Documentation/trace/ftrace.rst.
  54. Also, the unregister_fprobe() will guarantee that both enter and exit
  55. handlers are no longer being called by functions after unregister_fprobe()
  56. returns as same as unregister_ftrace_function().
  57. The fprobe entry/exit handler
  58. =============================
  59. The prototype of the entry/exit callback function are as follows:
  60. .. code-block:: c
  61. int entry_callback(struct fprobe *fp, unsigned long entry_ip, unsigned long ret_ip, struct ftrace_regs *fregs, void *entry_data);
  62. void exit_callback(struct fprobe *fp, unsigned long entry_ip, unsigned long ret_ip, struct ftrace_regs *fregs, void *entry_data);
  63. Note that the @entry_ip is saved at function entry and passed to exit
  64. handler.
  65. If the entry callback function returns !0, the corresponding exit callback
  66. will be cancelled.
  67. @fp
  68. This is the address of `fprobe` data structure related to this handler.
  69. You can embed the `fprobe` to your data structure and get it by
  70. container_of() macro from @fp. The @fp must not be NULL.
  71. @entry_ip
  72. This is the ftrace address of the traced function (both entry and exit).
  73. Note that this may not be the actual entry address of the function but
  74. the address where the ftrace is instrumented.
  75. @ret_ip
  76. This is the return address that the traced function will return to,
  77. somewhere in the caller. This can be used at both entry and exit.
  78. @fregs
  79. This is the `ftrace_regs` data structure at the entry and exit. This
  80. includes the function parameters, or the return values. So user can
  81. access thos values via appropriate `ftrace_regs_*` APIs.
  82. @entry_data
  83. This is a local storage to share the data between entry and exit handlers.
  84. This storage is NULL by default. If the user specify `exit_handler` field
  85. and `entry_data_size` field when registering the fprobe, the storage is
  86. allocated and passed to both `entry_handler` and `exit_handler`.
  87. Entry data size and exit handlers on the same function
  88. ======================================================
  89. Since the entry data is passed via per-task stack and it has limited size,
  90. the entry data size per probe is limited to `15 * sizeof(long)`. You also need
  91. to take care that the different fprobes are probing on the same function, this
  92. limit becomes smaller. The entry data size is aligned to `sizeof(long)` and
  93. each fprobe which has exit handler uses a `sizeof(long)` space on the stack,
  94. you should keep the number of fprobes on the same function as small as
  95. possible.
  96. Share the callbacks with kprobes
  97. ================================
  98. Since the recursion safeness of the fprobe (and ftrace) is a bit different
  99. from the kprobes, this may cause an issue if user wants to run the same
  100. code from the fprobe and the kprobes.
  101. Kprobes has per-cpu 'current_kprobe' variable which protects the kprobe
  102. handler from recursion in all cases. On the other hand, fprobe uses
  103. only ftrace_test_recursion_trylock(). This allows interrupt context to
  104. call another (or same) fprobe while the fprobe user handler is running.
  105. This is not a matter if the common callback code has its own recursion
  106. detection, or it can handle the recursion in the different contexts
  107. (normal/interrupt/NMI.)
  108. But if it relies on the 'current_kprobe' recursion lock, it has to check
  109. kprobe_running() and use kprobe_busy_*() APIs.
  110. Fprobe has FPROBE_FL_KPROBE_SHARED flag to do this. If your common callback
  111. code will be shared with kprobes, please set FPROBE_FL_KPROBE_SHARED
  112. *before* registering the fprobe, like:
  113. .. code-block:: c
  114. fprobe.flags = FPROBE_FL_KPROBE_SHARED;
  115. register_fprobe(&fprobe, "func*", NULL);
  116. This will protect your common callback from the nested call.
  117. The missed counter
  118. ==================
  119. The `fprobe` data structure has `fprobe::nmissed` counter field as same as
  120. kprobes.
  121. This counter counts up when;
  122. - fprobe fails to take ftrace_recursion lock. This usually means that a function
  123. which is traced by other ftrace users is called from the entry_handler.
  124. - fprobe fails to setup the function exit because of failing to allocate the
  125. data buffer from the per-task shadow stack.
  126. The `fprobe::nmissed` field counts up in both cases. Therefore, the former
  127. skips both of entry and exit callback and the latter skips the exit
  128. callback, but in both case the counter will increase by 1.
  129. Note that if you set the FTRACE_OPS_FL_RECURSION and/or FTRACE_OPS_FL_RCU to
  130. `fprobe::ops::flags` (ftrace_ops::flags) when registering the fprobe, this
  131. counter may not work correctly, because ftrace skips the fprobe function which
  132. increase the counter.
  133. Functions and structures
  134. ========================
  135. .. kernel-doc:: include/linux/fprobe.h
  136. .. kernel-doc:: kernel/trace/fprobe.c