Quoting Matthew Auld (2019-08-16 11:03:26)
> If we are leaking nodes don't hide it. Also stop trying to be
> "defensive" and instead embrace Kasan et al.
If you want to go even further, record the stacks of each allocator.
As we are using kmalloc of each node and operate like a cache, we can do
something like kmemleak_update_trace() on i915_buddy_alloc().
diff --git a/drivers/gpu/drm/i915/i915_buddy.c b/drivers/gpu/drm/i915/i915_buddy.c
index b679ab6fd889..3b30e05ffe53 100644
--- a/drivers/gpu/drm/i915/i915_buddy.c
+++ b/drivers/gpu/drm/i915/i915_buddy.c
@@ -3,6 +3,7 @@
* Copyright © 2019 Intel Corporation
*/
+#include <linux/kmemleak.h>
#include <linux/slab.h>
#include "i915_buddy.h"
@@ -309,6 +310,7 @@ i915_buddy_alloc(struct i915_buddy_mm *mm, unsigned int order)
}
mark_allocated(block);
+ kmemleak_update_trace(block);
return block;
should do the trick
> Signed-off-by: Matthew Auld <matthew.auld@xxxxxxxxx>
> Cc: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx>
> ---
> drivers/gpu/drm/i915/i915_buddy.c | 7 +------
> 1 file changed, 1 insertion(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_buddy.c b/drivers/gpu/drm/i915/i915_buddy.c
> index b679ab6fd889..5995247fdf76 100644
> --- a/drivers/gpu/drm/i915/i915_buddy.c
> +++ b/drivers/gpu/drm/i915/i915_buddy.c
> @@ -171,15 +171,10 @@ int i915_buddy_init(struct i915_buddy_mm *mm, u64 size, u64 chunk_size)
>
> void i915_buddy_fini(struct i915_buddy_mm *mm)
> {
> - int err = 0;
> int i;
>
> for (i = 0; i < mm->n_roots; ++i) {
> - if (!i915_buddy_block_is_free(mm->roots[i])) {
> - err = -EBUSY;
> - continue;
> - }
> -
> + GEM_WARN_ON(!i915_buddy_block_is_free(mm->roots[i]));
> i915_block_free(mm->roots[i]);
> }
>
> --
> 2.20.1
>
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
