Integrate kmemleaks and igt

[Gustavo Sousa]

Hi, Peter.

Quoting Peter Senna Tschudin (2025-06-18 08:58:07-03:00)
>Dear Gustavo,
>
>I am reaching out to you after Lucas suggested me to contact you about
>integrating kmemleaks with igt.
>
>Currently igt_runner has the -k option allowing the user to choose
>between running one kmemleak scan after all tests, or to run one scan
>after each test.
>
>The problem with these approaches is that running once after all tests
>is not very useful, and running one scan after each test imposes a large
>performance overhead, making it not practical for our CI.
>
>Lucas suggested an interesting alternative: Run a scan before module
>bind and another after module unbind. This way we will add a relatively
>small overhead while strategically running scans when we are more likely
>to catch something interesting.
>
>The problem now becomes how integrate kmemleak scans around bind and
>unbind operations. Lucas suggested new hooks IGT_HOOK_PRE_MODULE_BIND
>/IGT_HOOK_POST_MODULE_UNBIND as a potential approach.

What would "bind"/"unbind" mean in this case?

>
>Two related questions for you Gustavo. Any thoughts or preferences about
>collecting kmemleak scans around bind operations? What about these new
>proposed hooks, do they seem like the way to go?

For the first question, I think I need to understand the meaning of
bind. :-)

For the second question, yeah, using the existing hook framework would
be nice, because we would have a single implementation for attaching
functions/scripts at specific points of execution (a.k.a hook
events).

The current hook infrastructure only accepts strings provided by the end
user, which are executed as shell scripts. To allow internal usage as
well, we would need to extend the implementation to allow attaching
function pointers.

Another thing to consider is that currently hook events work at the
"test process" level. The runner will forward hook options when calling
the test binary. So, depending on what "bind"/"unbind" means, we might
to also need to extend the implementation to allow hooks to be used
outside of test processes (i.e. in the runner's process).

--
Gustavo Sousa