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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 20 Mar 2023 16:30:36 +0100
From:   Andrzej Hajda <andrzej.hajda@...el.com>
To:     Andi Shyti <andi.shyti@...ux.intel.com>
Cc:     Chris Wilson <chris.p.wilson@...el.com>, netdev@...r.kernel.org,
        intel-gfx@...ts.freedesktop.org, linux-kernel@...r.kernel.org,
        Chris Wilson <chris@...is-wilson.co.uk>,
        Eric Dumazet <edumazet@...gle.com>,
        dri-devel@...ts.freedesktop.org, Daniel Vetter <daniel@...ll.ch>,
        Rodrigo Vivi <rodrigo.vivi@...el.com>,
        Jakub Kicinski <kuba@...nel.org>,
        David Airlie <airlied@...il.com>,
        Dmitry Vyukov <dvyukov@...gle.com>
Subject: Re: [Intel-gfx] [PATCH v4 01/10] lib/ref_tracker: add unlocked leak
 print helper

On 19.03.2023 23:59, Andi Shyti wrote:
> 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 '__'?
> 

OK, 'locked' convention looks better.

Regards
Andrzej

>> +{
>> +	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