kmemleaks and our CI

kmemleaks and our CI

[Peter Senna Tschudin]

Dear xe kernel driver developers,

I am looking into sane ways to integrate kmemleaks with our CI. By sane I mean ways that will help us find and fix leaks while not overwhelming us with noise and our DUTs with unnecessary load.

It came to my attention that we may be running _all_ our CI tests with kmemleak enabled and scanning. To me this has two problems. The first is that it slows down memory allocation and freeing, no big deal.

The second problem however, is that if all our CI tests are indeed running with kmemleak enabled and scanning, it means that we are not testing our drivers in a kernel without kmemleak. I don't have numbers, but I assume that a large portion of real world use cases will have kmemleak disabled.

Is it a problem to run all our CI tests with kmemleak enabled and scanning?

Thanks,

Peter

Re: kmemleaks and our CI

[Lucas De Marchi]

On Tue, Dec 03, 2024 at 05:48:59PM +0100, Peter Senna Tschudin wrote:
>Dear xe kernel driver developers,
>
>I am looking into sane ways to integrate kmemleaks with our CI. By sane I mean ways that will help us find and fix leaks while not overwhelming us with noise and our DUTs with unnecessary load.

I think we will need to try a couple of approaches and see how well we
can support. Maybe we will have to filter leaks originated from
elsewhere... not sure. I think it's important:

1) to be easily turned on/off
2) to be easy to reproduce on dev machines - it's awful when things are
    deeply integrated in the CI infra and just a few people know how to
    reproduce it

So, I think it neeeds to be a command line option for igt_runner.
Something like the abort-on-monitored thing it has. But maybe we
shouldn't abort, just warn.

>
>It came to my attention that we may be running _all_ our CI tests with kmemleak enabled and scanning. To me this has two problems. The first is that it slows down memory allocation and freeing, no big deal.

indeed, no big deal

>
>The second problem however, is that if all our CI tests are indeed running with kmemleak enabled and scanning, it means that we are not testing our drivers in a kernel without kmemleak. I don't have numbers, but I assume that a large portion of real world use cases will have kmemleak disabled.
>
>Is it a problem to run all our CI tests with kmemleak enabled and scanning?


not a big deal. If we were running benchmarks and trying to
compare the performance before/after etc, it could be problematic as a
bunch of other debug configs we also need.  This is not the purpose of
our CI - there are other CIs, particularly for the userspace libraries,
that do that.

See our repo for maintaining the kernel config:
https://gitlab.freedesktop.org/drm/xe/ci/-/tree/main/kernel?ref_type=heads

There are other build variants that are also built by CI. CI itself
uses the debug variant, but others are welcome to use the nodebug and
propose changes.

Lucas De Marchi

>
>Thanks,
>
>Peter