[Intel-gfx] [PATCH v4 01/10] lib/ref_tracker: add unlocked leak print helper

Andi Shyti andi.shyti at linux.intel.com
Sun Mar 19 22:59:49 UTC 2023


Hi Andrzej,

[...]

> diff --git a/lib/ref_tracker.c b/lib/ref_tracker.c
> index dc7b14aa3431e2..5e9f90bbf771b0 100644
> --- a/lib/ref_tracker.c
> +++ b/lib/ref_tracker.c
> @@ -14,6 +14,38 @@ struct ref_tracker {
>  	depot_stack_handle_t	free_stack_handle;
>  };
>  
> +void __ref_tracker_dir_print(struct ref_tracker_dir *dir,
> +			   unsigned int display_limit)

can we call this ref_tracker_dir_print_locked() instead of using
the '__'?

> +{
> +	struct ref_tracker *tracker;
> +	unsigned int i = 0;
> +
> +	lockdep_assert_held(&dir->lock);
> +
> +	list_for_each_entry(tracker, &dir->list, head) {
> +		if (i < display_limit) {
> +			pr_err("leaked reference.\n");
> +			if (tracker->alloc_stack_handle)
> +				stack_depot_print(tracker->alloc_stack_handle);
> +			i++;
> +		} else {
> +			break;
> +		}
> +	}
> +}
> +EXPORT_SYMBOL(__ref_tracker_dir_print);
> +
> +void ref_tracker_dir_print(struct ref_tracker_dir *dir,
> +			   unsigned int display_limit)
> +{
> +	unsigned long flags;
> +
> +	spin_lock_irqsave(&dir->lock, flags);
> +	__ref_tracker_dir_print(dir, display_limit);
> +	spin_unlock_irqrestore(&dir->lock, flags);
> +}
> +EXPORT_SYMBOL(ref_tracker_dir_print);
> +
>  void ref_tracker_dir_exit(struct ref_tracker_dir *dir)
>  {
>  	struct ref_tracker *tracker, *n;
> @@ -27,13 +59,13 @@ void ref_tracker_dir_exit(struct ref_tracker_dir *dir)
>  		kfree(tracker);
>  		dir->quarantine_avail++;
>  	}
> -	list_for_each_entry_safe(tracker, n, &dir->list, head) {
> -		pr_err("leaked reference.\n");
> -		if (tracker->alloc_stack_handle)
> -			stack_depot_print(tracker->alloc_stack_handle);
> +	if (!list_empty(&dir->list)) {
> +		__ref_tracker_dir_print(dir, 16);
>  		leak = true;
> -		list_del(&tracker->head);
> -		kfree(tracker);
> +		list_for_each_entry_safe(tracker, n, &dir->list, head) {
> +			list_del(&tracker->head);
> +			kfree(tracker);
> +		}

Just thinking whether this should go on a different patch, but I
don't have a strong opinion.

Looks good!

Andi


More information about the Intel-gfx mailing list