Re: [PATCH 5/8] kernel: convert process/thread iterators to for_each_*_rcu

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] Mixing goto-based error cleanup with guard() scopes in the same function (`alloc_retstack_tasklist`).
--

commit f2b0046bb431ebefb3d059e22788f2810f0e6684
Author: Ye Liu <liuye@kylinos.cn>
kernel: convert process/thread iterators to for_each_*_rcu

This commit converts multiple manual rcu_read_lock() and iterator blocks
across the kernel to use the new for_each_*_rcu() macros.

> diff --git a/kernel/trace/fgraph.c b/kernel/trace/fgraph.c
> index 40d373d65f9b9..e522433ec8a5a 100644
> --- a/kernel/trace/fgraph.c
> +++ b/kernel/trace/fgraph.c
[ ... ]
> @@ -1057,11 +1057,10 @@ static int alloc_retstack_tasklist(unsigned long **ret_stack_list)
>  		}
>  	}
>  
> -	rcu_read_lock();
> -	for_each_process_thread(g, t) {
> +	for_each_process_thread_rcu(g, t) {
>  		if (start == end) {
>  			ret = -EAGAIN;
> -			goto unlock;
> +			goto free;

[Severity: Low]
Does this change violate the cleanup subsystem guidelines by mixing paradigms?

The for_each_process_thread_rcu() macro expands to include a
scoped_guard(rcu). However, alloc_retstack_tasklist() still uses a goto free
statement to manually clean up the ret_stack_list array allocations upon error.

According to the kernel guidelines in include/linux/cleanup.h, the
expectation is that a given function either converts all resources requiring
a goto cleanup to scope-based cleanup, or converts none of them. Mixing
goto-based error handling with guard() or scoped_guard() scopes in the same
function should be avoided.

>  		}
>  
>  		if (t->ret_stack == NULL) {
[ ... ]
> @@ -1074,9 +1073,6 @@ static int alloc_retstack_tasklist(unsigned long **ret_stack_list)
>  			t->ret_stack = ret_stack_list[start++];
>  		}
>  	}
> -
> -unlock:
> -	rcu_read_unlock();
>  free:
>  	for (i = start; i < end; i++)
>  		kmem_cache_free(fgraph_stack_cachep, ret_stack_list[i]);

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260904083001.553587-1-ye.liu@linux.dev?part=5